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:
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
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
"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
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
"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
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
Stephane TOUGARD
helios wrote:
TCP/IP n'est pas partout meme si ilest present sur presque tout c'est le presque qui fait la difference
Quelques systemes obsoletes ne l'ont pas, en effet.
-- 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:
TCP/IP n'est pas partout meme si ilest present sur presque tout c'est le
presque qui fait la difference
Quelques systemes obsoletes ne l'ont pas, en effet.
--
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
TCP/IP n'est pas partout meme si ilest present sur presque tout c'est le presque qui fait la difference
Quelques systemes obsoletes ne l'ont pas, en effet.
-- 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
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
Ben oui, et?
A c'est clair que si on ne change pas les tables pour les adapter au type de SGBD utilisé, ça ne risque pas de fonctionner correctement (*).
les fichier avait ete SQLise avant (mis en format relationnel c'est la conversion que tu as fait en changeant les tables qui consiste a eclate le MV )
Et à partir des *mes* tables, tu fais comment en multivalué?
tu fait le meme lien qu'en SGBDR quand on peut gerer un champ multivalue on sait gere un champ singlevalue
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
Ben oui, et?
A c'est clair que si on ne change pas les tables pour les adapter au type
de SGBD utilisé, ça ne risque pas de fonctionner correctement (*).
les fichier avait ete SQLise avant (mis en format relationnel c'est la
conversion que tu as fait en changeant les tables qui consiste a eclate le
MV )
Et à partir des *mes* tables, tu fais comment en multivalué?
tu fait le meme lien qu'en SGBDR quand on peut gerer un champ multivalue on
sait gere un champ singlevalue
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
Ben oui, et?
A c'est clair que si on ne change pas les tables pour les adapter au type de SGBD utilisé, ça ne risque pas de fonctionner correctement (*).
les fichier avait ete SQLise avant (mis en format relationnel c'est la conversion que tu as fait en changeant les tables qui consiste a eclate le MV )
Et à partir des *mes* tables, tu fais comment en multivalué?
tu fait le meme lien qu'en SGBDR quand on peut gerer un champ multivalue on sait gere un champ singlevalue
Stephane TOUGARD
helios wrote:
les executables sous pick qui exploite les donnes sont tranferable les executable C qui exploite oracle non
On s'en fout un peu ceci etant dit. Ce qui est important ce sont les datas, pas les binaires qui les lisent.
-- 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:
les executables sous pick qui exploite les donnes sont tranferable les
executable C qui exploite oracle non
On s'en fout un peu ceci etant dit. Ce qui est important ce sont les
datas, pas les binaires qui les lisent.
--
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
les executables sous pick qui exploite les donnes sont tranferable les executable C qui exploite oracle non
On s'en fout un peu ceci etant dit. Ce qui est important ce sont les datas, pas les binaires qui les lisent.
-- 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
Stephane Zuckerman
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).
il te faudra a peux pres 8000 table
D'où sors-tu ce nombre ?
-- "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)
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).
il te faudra a peux pres 8000 table
D'où sors-tu ce nombre ?
--
"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)
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).
il te faudra a peux pres 8000 table
D'où sors-tu ce nombre ?
-- "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)
remy
"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
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" <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
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" 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
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
Michel Talon
Stephane TOUGARD wrote: x
Allo la lune ici la terre. Dans un systeme Unix, le noyau accede au materiel et il est le seul qui a cette prerogative la. Si tu parles avec un device, c'est que tu parles avec le noyau et lui transmet les ordres.
A priori si tu peux accéder à la mémoire du noyau, sous root, et tu peux, tu peux lui faire exécuter ce que tu veux, y compris des accés directs au matériel (*). je ne dis pas que c'est facile, mais c'est faisable. Sous un système Unix, root est tout puissant.
(*) incidemment c'est bien ce que fait le driver X de la carte vidéo, sans utiliser des services du noyau.
Stephane TOUGARD wrote:
x
Allo la lune ici la terre. Dans un systeme Unix, le noyau accede au
materiel et il est le seul qui a cette prerogative la. Si tu parles avec
un device, c'est que tu parles avec le noyau et lui transmet les ordres.
A priori si tu peux accéder à la mémoire du noyau, sous root, et tu
peux, tu peux lui faire exécuter ce que tu veux, y compris des accés
directs au matériel (*). je ne dis pas que c'est facile, mais c'est
faisable. Sous un système Unix, root est tout puissant.
(*) incidemment c'est bien ce que fait le driver X de la carte vidéo,
sans utiliser des services du noyau.
Allo la lune ici la terre. Dans un systeme Unix, le noyau accede au materiel et il est le seul qui a cette prerogative la. Si tu parles avec un device, c'est que tu parles avec le noyau et lui transmet les ordres.
A priori si tu peux accéder à la mémoire du noyau, sous root, et tu peux, tu peux lui faire exécuter ce que tu veux, y compris des accés directs au matériel (*). je ne dis pas que c'est facile, mais c'est faisable. Sous un système Unix, root est tout puissant.
(*) incidemment c'est bien ce que fait le driver X de la carte vidéo, sans utiliser des services du noyau.
Stephane TOUGARD
Vincent Bernat wrote:
Pfff, Kermit a 6 000 000 d'utilisateurs !
Le minitel, ca marche aussi via Kermit ?
Enfin bon, c'est vrai que la grenouille est particulierement sympa.
-- 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:
Pfff, Kermit a 6 000 000 d'utilisateurs !
Le minitel, ca marche aussi via Kermit ?
Enfin bon, c'est vrai que la grenouille est particulierement sympa.
--
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
Enfin bon, c'est vrai que la grenouille est particulierement sympa.
-- 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
Jerome Lambert
helios wrote: (...)
Et à partir des *mes* tables, tu fais comment en multivalué?
tu fait le meme lien qu'en SGBDR quand on peut gerer un champ multivalue on sait gere un champ singlevalue
Mouais, donc l'intéret de ton machin est quasi-nul, puisqu'une base relationnelle intelligemment conçue rend les mêmes services...
helios wrote:
(...)
Et à partir des *mes* tables, tu fais comment en multivalué?
tu fait le meme lien qu'en SGBDR quand on peut gerer un champ multivalue on
sait gere un champ singlevalue
Mouais, donc l'intéret de ton machin est quasi-nul, puisqu'une base
relationnelle intelligemment conçue rend les mêmes services...
