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
"Stephane Zuckerman" a écrit dans le message de news:
sur un exemple basic l'avantage n'est pas evident mais prend un base de 60million de fiches de 500 champs multivalue de niveau 4 et calcul le nombre
de table necessaire et la redondance d'info
La redondance des infos n'existera pas si la base est correctement "spécifiée" (je n'arrive pas à trouver le bon terme).
si tu as
1 100 1 200 1 300
au lieu de
1 100,200,300
dans le premier cas tu as des infos redondante
il te faudra a peux pres 8000 table
D'où sors-tu ce nombre ?
500X 2^4 = 8000
Stephane TOUGARD
Vincent Bernat wrote:
Mais bon, être un cancre en maths ne préjuge pas de vos connaissances sur PICK. Vous passez juste pour un clown.
N'empeche que passer pour un clown en decrivant un logiciel que personne ne connait, c'est quand meme tres fort.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
Vincent Bernat wrote:
Mais bon, être un cancre en maths ne préjuge pas de vos connaissances
sur PICK. Vous passez juste pour un clown.
N'empeche que passer pour un clown en decrivant un logiciel que personne
ne connait, c'est quand meme tres fort.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
Mais bon, être un cancre en maths ne préjuge pas de vos connaissances sur PICK. Vous passez juste pour un clown.
N'empeche que passer pour un clown en decrivant un logiciel que personne ne connait, c'est quand meme tres fort.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
helios
"remy" a écrit dans le message de news:42e8d2ad$0$22306$
"Stephane Zuckerman" a écrit dans le message de news:
Avec le lien adéquat entre les "Clients". Il est où, le problème?
le problem est que c'est pas la question tu as changer la table 1
Admettons (pour la forme). Etant donné que j'accède aux champs de mon SGBDR avec la _même_ facilité (les requêtes imbriquées sont là pour ça entre autres) que vous pour accéder à un champ multivalué, où est le réel
avantage ? Ca fait moins de tables ? Et après ?
L'important est de gérer les relations (n,m) entre deux types d'entités. Une fois que c'est fait, où est le problème ? Honnêtement, lorsqu'une base
est bien conçue, on n'est pas censé la retoucher du jour au lendemain, MV
ou pas MV. Du coup, si je décide d'utiliser un SGBDR, comme _au_final_ je
récupère les mêmes résultats que pour un SGBD MV, je ne vois pas l'avantage qu'a l'un sur l'autre en termes de mérite.
--
sur un exemple basic l'avantage n'est pas evident mais prend un base de 60million de fiches de 500 champs multivalue de niveau 4 et calcul le nombre
de table necessaire et la redondance d'info
60 million*500*4
pas mal le dico
non le dico fait 500 entree
il te faudra a peux pres 8000 table pour la remplacer ce qui veux dire a peut pres un espace media de 4000 fois plus important une puissance de calcul beaucoup plus importante des disque plus rapide plus de memoire central .....bref un inverstiment matos concequent pour obtenir la meme chose
qui dit 8000 tables dis 8000 coherence a faire
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
"remy" <remy@fctpas.fr> a écrit dans le message de
news:42e8d2ad$0$22306$8fcfb975@news.wanadoo.fr...
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0507281407481.342864@vega.utc.fr...
Avec le lien adéquat entre les "Clients". Il est où, le problème?
le problem est que c'est pas la question tu as changer la table 1
Admettons (pour la forme). Etant donné que j'accède aux champs de mon
SGBDR avec la _même_ facilité (les requêtes imbriquées sont là pour ça
entre autres) que vous pour accéder à un champ multivalué, où est le
réel
avantage ? Ca fait moins de tables ? Et après ?
L'important est de gérer les relations (n,m) entre deux types d'entités.
Une fois que c'est fait, où est le problème ? Honnêtement, lorsqu'une
base
est bien conçue, on n'est pas censé la retoucher du jour au lendemain,
MV
ou pas MV. Du coup, si je décide d'utiliser un SGBDR, comme _au_final_
je
récupère les mêmes résultats que pour un SGBD MV, je ne vois pas
l'avantage qu'a l'un sur l'autre en termes de mérite.
--
sur un exemple basic l'avantage n'est pas evident mais prend un base de
60million de fiches de 500 champs multivalue de niveau 4 et calcul le
nombre
de table necessaire et la redondance d'info
60 million*500*4
pas mal le dico
non le dico fait 500 entree
il te faudra a peux pres 8000 table pour la remplacer ce qui veux dire a
peut pres un espace media de 4000 fois plus important une puissance de
calcul beaucoup plus importante des disque plus rapide plus de memoire
central .....bref un inverstiment matos concequent pour obtenir la meme
chose
qui dit 8000 tables dis 8000 coherence a faire
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
"remy" a écrit dans le message de news:42e8d2ad$0$22306$
"Stephane Zuckerman" a écrit dans le message de news:
Avec le lien adéquat entre les "Clients". Il est où, le problème?
le problem est que c'est pas la question tu as changer la table 1
Admettons (pour la forme). Etant donné que j'accède aux champs de mon SGBDR avec la _même_ facilité (les requêtes imbriquées sont là pour ça entre autres) que vous pour accéder à un champ multivalué, où est le réel
avantage ? Ca fait moins de tables ? Et après ?
L'important est de gérer les relations (n,m) entre deux types d'entités. Une fois que c'est fait, où est le problème ? Honnêtement, lorsqu'une base
est bien conçue, on n'est pas censé la retoucher du jour au lendemain, MV
ou pas MV. Du coup, si je décide d'utiliser un SGBDR, comme _au_final_ je
récupère les mêmes résultats que pour un SGBD MV, je ne vois pas l'avantage qu'a l'un sur l'autre en termes de mérite.
--
sur un exemple basic l'avantage n'est pas evident mais prend un base de 60million de fiches de 500 champs multivalue de niveau 4 et calcul le nombre
de table necessaire et la redondance d'info
60 million*500*4
pas mal le dico
non le dico fait 500 entree
il te faudra a peux pres 8000 table pour la remplacer ce qui veux dire a peut pres un espace media de 4000 fois plus important une puissance de calcul beaucoup plus importante des disque plus rapide plus de memoire central .....bref un inverstiment matos concequent pour obtenir la meme chose
qui dit 8000 tables dis 8000 coherence a faire
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Stephane Zuckerman
D'où sors-tu ce nombre ?
500X 2^4 = 8000 Ah oui, mais non. Si tu conçois bien ta base en fonction d'une approche
relationnelle, certaines choses "obligatoires" dans ton modèle ne le sont plus dans le nouveau, et inversement. Je ne suis clairement pas certain que ton calcul "direct" soit aussi facile à faire.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
D'où sors-tu ce nombre ?
500X 2^4 = 8000
Ah oui, mais non. Si tu conçois bien ta base en fonction d'une approche
relationnelle, certaines choses "obligatoires" dans ton modèle ne le sont
plus dans le nouveau, et inversement. Je ne suis clairement pas certain
que ton calcul "direct" soit aussi facile à faire.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
500X 2^4 = 8000 Ah oui, mais non. Si tu conçois bien ta base en fonction d'une approche
relationnelle, certaines choses "obligatoires" dans ton modèle ne le sont plus dans le nouveau, et inversement. Je ne suis clairement pas certain que ton calcul "direct" soit aussi facile à faire.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Stephane TOUGARD
helios wrote:
pour les math j'ai eu 17 de moyennes de la 6eme a la fin de mes etudes et le dernier diplome que j'ai passe j'ai eu 18 en math applique et a tout les concours administratif j'ai eu 20/20 en math donc je penses ne pas avoir ete cancre en math
Comme quoi on retrouve toujours quelque part ce qu'on a perdu ailleurs.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
helios wrote:
pour les math j'ai eu 17 de moyennes de la 6eme a la fin de mes etudes et le
dernier diplome que j'ai passe j'ai eu 18 en math applique et a tout les
concours administratif j'ai eu 20/20 en math donc je penses ne pas avoir ete
cancre en math
Comme quoi on retrouve toujours quelque part ce qu'on a perdu ailleurs.
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
pour les math j'ai eu 17 de moyennes de la 6eme a la fin de mes etudes et le dernier diplome que j'ai passe j'ai eu 18 en math applique et a tout les concours administratif j'ai eu 20/20 en math donc je penses ne pas avoir ete cancre en math
Comme quoi on retrouve toujours quelque part ce qu'on a perdu ailleurs.
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
remy
"remy" a écrit dans le message de news:42e8d2ad$0$22306$
"Stephane Zuckerman" a écrit dans le message de news:
Avec le lien adéquat entre les "Clients". Il est où, le problème?
le problem est que c'est pas la question tu as changer la table 1
Admettons (pour la forme). Etant donné que j'accède aux champs de mon SGBDR avec la _même_ facilité (les requêtes imbriquées sont là pour ça entre autres) que vous pour accéder à un champ multivalué, où est le
réel
avantage ? Ca fait moins de tables ? Et après ?
L'important est de gérer les relations (n,m) entre deux types d'entités. Une fois que c'est fait, où est le problème ? Honnêtement, lorsqu'une
base
est bien conçue, on n'est pas censé la retoucher du jour au lendemain,
MV
ou pas MV. Du coup, si je décide d'utiliser un SGBDR, comme _au_final_
je
récupère les mêmes résultats que pour un SGBD MV, je ne vois pas l'avantage qu'a l'un sur l'autre en termes de mérite.
--
sur un exemple basic l'avantage n'est pas evident mais prend un base de 60million de fiches de 500 champs multivalue de niveau 4 et calcul le
nombre
de table necessaire et la redondance d'info
60 million*500*4
pas mal le dico
non le dico fait 500 entree
et les 60 million de fiches elle sont ou ?
il te faudra a peux pres 8000 table pour la remplacer ce qui veux dire a peut pres un espace media de 4000 fois plus important une puissance de calcul beaucoup plus importante des disque plus rapide plus de memoire central .....bref un inverstiment matos concequent pour obtenir la meme chose
qui dit 8000 tables dis 8000 coherence a faire
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
"remy" <remy@fctpas.fr> a écrit dans le message de
news:42e8d2ad$0$22306$8fcfb975@news.wanadoo.fr...
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0507281407481.342864@vega.utc.fr...
Avec le lien adéquat entre les "Clients". Il est où, le problème?
le problem est que c'est pas la question tu as changer la table 1
Admettons (pour la forme). Etant donné que j'accède aux champs de mon
SGBDR avec la _même_ facilité (les requêtes imbriquées sont là pour ça
entre autres) que vous pour accéder à un champ multivalué, où est le
réel
avantage ? Ca fait moins de tables ? Et après ?
L'important est de gérer les relations (n,m) entre deux types d'entités.
Une fois que c'est fait, où est le problème ? Honnêtement, lorsqu'une
base
est bien conçue, on n'est pas censé la retoucher du jour au lendemain,
MV
ou pas MV. Du coup, si je décide d'utiliser un SGBDR, comme _au_final_
je
récupère les mêmes résultats que pour un SGBD MV, je ne vois pas
l'avantage qu'a l'un sur l'autre en termes de mérite.
--
sur un exemple basic l'avantage n'est pas evident mais prend un base de
60million de fiches de 500 champs multivalue de niveau 4 et calcul le
nombre
de table necessaire et la redondance d'info
60 million*500*4
pas mal le dico
non le dico fait 500 entree
et les 60 million de fiches elle sont ou ?
il te faudra a peux pres 8000 table pour la remplacer ce qui veux dire a
peut pres un espace media de 4000 fois plus important une puissance de
calcul beaucoup plus importante des disque plus rapide plus de memoire
central .....bref un inverstiment matos concequent pour obtenir la meme
chose
qui dit 8000 tables dis 8000 coherence a faire
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
"remy" a écrit dans le message de news:42e8d2ad$0$22306$
"Stephane Zuckerman" a écrit dans le message de news:
Avec le lien adéquat entre les "Clients". Il est où, le problème?
le problem est que c'est pas la question tu as changer la table 1
Admettons (pour la forme). Etant donné que j'accède aux champs de mon SGBDR avec la _même_ facilité (les requêtes imbriquées sont là pour ça entre autres) que vous pour accéder à un champ multivalué, où est le
réel
avantage ? Ca fait moins de tables ? Et après ?
L'important est de gérer les relations (n,m) entre deux types d'entités. Une fois que c'est fait, où est le problème ? Honnêtement, lorsqu'une
base
est bien conçue, on n'est pas censé la retoucher du jour au lendemain,
MV
ou pas MV. Du coup, si je décide d'utiliser un SGBDR, comme _au_final_
je
récupère les mêmes résultats que pour un SGBD MV, je ne vois pas l'avantage qu'a l'un sur l'autre en termes de mérite.
--
sur un exemple basic l'avantage n'est pas evident mais prend un base de 60million de fiches de 500 champs multivalue de niveau 4 et calcul le
nombre
de table necessaire et la redondance d'info
60 million*500*4
pas mal le dico
non le dico fait 500 entree
et les 60 million de fiches elle sont ou ?
il te faudra a peux pres 8000 table pour la remplacer ce qui veux dire a peut pres un espace media de 4000 fois plus important une puissance de calcul beaucoup plus importante des disque plus rapide plus de memoire central .....bref un inverstiment matos concequent pour obtenir la meme chose
qui dit 8000 tables dis 8000 coherence a faire
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
helios
et moi je ne comprends pas
quelle est la difference entre parcourir un index..index..index et rechercher un pointeur dans un dico de dico de dico
d'un point de vue performance bien sur pas de la structure quoique
--
cas 1 tu cherche un index..index..index cas 2 c'est directement le dico, l'article de dico geres le multivalue aussi donc acces direct
l'article dico peut dire que la valeur recherche sera les 3eme sous sous sous valeurs de des sous sous valeurs 2 de des sous valeurs 5 de des valeurs 7 des l'attribut 8 des l'articles du fichier (table)
et moi je ne comprends pas
quelle est la difference entre parcourir un index..index..index
et rechercher un pointeur dans un dico de dico de dico
d'un point de vue performance bien sur pas de la structure quoique
--
cas 1 tu cherche un index..index..index
cas 2 c'est directement le dico, l'article de dico geres le multivalue
aussi donc acces direct
l'article dico peut dire que la valeur recherche sera les 3eme sous sous
sous valeurs de des sous sous valeurs 2 de des sous valeurs 5 de des valeurs
7 des l'attribut 8 des l'articles du fichier (table)
quelle est la difference entre parcourir un index..index..index et rechercher un pointeur dans un dico de dico de dico
d'un point de vue performance bien sur pas de la structure quoique
--
cas 1 tu cherche un index..index..index cas 2 c'est directement le dico, l'article de dico geres le multivalue aussi donc acces direct
l'article dico peut dire que la valeur recherche sera les 3eme sous sous sous valeurs de des sous sous valeurs 2 de des sous valeurs 5 de des valeurs 7 des l'attribut 8 des l'articles du fichier (table)
Lionel GRUHN
Le 10 Thermidor de l'An CCXIII de la République sociale, universelle et indivisible, Stephane Zuckerman a écrit:
En matière de communications, kermit est dépassé depuis un bon moment. IPX/SPX aussi. Enfin, y'a un p'tit truc, TCP/IP, qui a l'air de bien marcher, cela dit.
T'en as entendu parler toi aussi ? un protocole qui passerait pas par le port serie, incroyable non ? Oui enfin, devant la puissance de kermit, je me demande si ça pourra tenir
le choc.
Quand je vois des technologies émergeantes comme ça, j'aimerais parfois être plus vieux d'une dizaine d'années pour savoir si ça va tenir ou pas...
Lionel
Le 10 Thermidor de l'An CCXIII de la République sociale, universelle et
indivisible, Stephane Zuckerman a écrit:
En matière de communications, kermit est dépassé depuis un bon moment.
IPX/SPX aussi. Enfin, y'a un p'tit truc, TCP/IP, qui a l'air de bien
marcher, cela dit.
T'en as entendu parler toi aussi ? un protocole qui passerait pas par le
port serie, incroyable non ?
Oui enfin, devant la puissance de kermit, je me demande si ça pourra tenir
le choc.
Quand je vois des technologies émergeantes comme ça, j'aimerais parfois être
plus vieux d'une dizaine d'années pour savoir si ça va tenir ou pas...
Le 10 Thermidor de l'An CCXIII de la République sociale, universelle et indivisible, Stephane Zuckerman a écrit:
En matière de communications, kermit est dépassé depuis un bon moment. IPX/SPX aussi. Enfin, y'a un p'tit truc, TCP/IP, qui a l'air de bien marcher, cela dit.
T'en as entendu parler toi aussi ? un protocole qui passerait pas par le port serie, incroyable non ? Oui enfin, devant la puissance de kermit, je me demande si ça pourra tenir
le choc.
Quand je vois des technologies émergeantes comme ça, j'aimerais parfois être plus vieux d'une dizaine d'années pour savoir si ça va tenir ou pas...
Lionel
helios
"Stephane Zuckerman" a écrit dans le message de news:
D'où sors-tu ce nombre ?
500X 2^4 = 8000 Ah oui, mais non. Si tu conçois bien ta base en fonction d'une approche
relationnelle, certaines choses "obligatoires" dans ton modèle ne le sont plus dans le nouveau, et inversement. Je ne suis clairement pas certain que ton calcul "direct" soit aussi facile à faire.
le modele relationnel a plus de contraite que le MV donc il y a ajout lors d'une SQLisation de table MV
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0507281452100.342864@vega.utc.fr...
D'où sors-tu ce nombre ?
500X 2^4 = 8000
Ah oui, mais non. Si tu conçois bien ta base en fonction d'une approche
relationnelle, certaines choses "obligatoires" dans ton modèle ne le sont
plus dans le nouveau, et inversement. Je ne suis clairement pas certain
que ton calcul "direct" soit aussi facile à faire.
le modele relationnel a plus de contraite que le MV donc il y a ajout lors
d'une SQLisation de table MV
"Stephane Zuckerman" a écrit dans le message de news:
D'où sors-tu ce nombre ?
500X 2^4 = 8000 Ah oui, mais non. Si tu conçois bien ta base en fonction d'une approche
relationnelle, certaines choses "obligatoires" dans ton modèle ne le sont plus dans le nouveau, et inversement. Je ne suis clairement pas certain que ton calcul "direct" soit aussi facile à faire.
le modele relationnel a plus de contraite que le MV donc il y a ajout lors d'une SQLisation de table MV
helios
non le dico fait 500 entree
et les 60 million de fiches elle sont ou ?
les fiches sont les articles du fichier le dico est les point d'entres dans
le fichier
fichier mec toto 001 cap;bep;bac 002 1980;1980;1982 003 lep,lep,ces
dico du fichier mec
diplome 001 a 002 1
annee 001 a 002 2
bahut 001 a 002 3
(article dico tronque a 2 champ en realite il y en a 10 pour le definir)
non le dico fait 500 entree
et les 60 million de fiches elle sont ou ?
les fiches sont les articles du fichier le dico est les point d'entres dans
le fichier
fichier mec
toto
001 cap;bep;bac
002 1980;1980;1982
003 lep,lep,ces
dico du fichier mec
diplome
001 a
002 1
annee
001 a
002 2
bahut
001 a
002 3
(article dico tronque a 2 champ en realite il y en a 10 pour le definir)
