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
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Jerome Lambert wrote:
En gros, oui.
Un lien un peu plus recommandable sur le bidule:
http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi
j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser
un bon vieux Shell et si vraiment on veux gerer des grosses tables en
mode clef valeurs (c'est quand meme vachement basique comme principe),
on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris
oui l'on a une cle unique par champs
plus il y a de donnees plus il y a de cles
bonjour les performance
et le dico sert a ameloirer les performances
cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut
cle n a cles n+100
coucou les trous
mais se qui me titille
il y a une limitation liee a la taille des cles
et vue le gaspillage il vaut mieux voir grand
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Stephane Zuckerman
celui qui pirate un SGBD c'est pas pour un acces root mais pour les donnees dans pick l'acces au donne est segmente en cas de crack dans un sgbd le crack d'un users donne acces au donne de tous
Honnêtement, tu ne maîtrises _absolument_pas_ le système de privilèges inhérent aux UNICES. A partir du moment où ton utilisateur accède au système PICK, que ce dernier est lancé *après* le noyau linux (car c'est proche d'un OS sans en être un), et que d'après tes propres dires, un utilisateur PICK = un utilisateur Linux, comment peux-tu affirmer qu'en cas de défaillance de PICK on ne peut pas obtenir des privilèges ?
-- "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)
celui qui pirate un SGBD c'est pas pour un acces root mais pour les donnees
dans pick l'acces au donne est segmente en cas de crack dans un sgbd le
crack d'un users donne acces au donne de tous
Honnêtement, tu ne maîtrises _absolument_pas_ le système de privilèges
inhérent aux UNICES. A partir du moment où ton utilisateur accède au
système PICK, que ce dernier est lancé *après* le noyau linux (car
c'est proche d'un OS sans en être un), et que d'après tes propres dires,
un utilisateur PICK = un utilisateur Linux, comment peux-tu affirmer qu'en
cas de défaillance de PICK on ne peut pas obtenir des privilèges ?
--
"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)
celui qui pirate un SGBD c'est pas pour un acces root mais pour les donnees dans pick l'acces au donne est segmente en cas de crack dans un sgbd le crack d'un users donne acces au donne de tous
Honnêtement, tu ne maîtrises _absolument_pas_ le système de privilèges inhérent aux UNICES. A partir du moment où ton utilisateur accède au système PICK, que ce dernier est lancé *après* le noyau linux (car c'est proche d'un OS sans en être un), et que d'après tes propres dires, un utilisateur PICK = un utilisateur Linux, comment peux-tu affirmer qu'en cas de défaillance de PICK on ne peut pas obtenir des privilèges ?
-- "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)
Jerome Lambert
"Stephane TOUGARD" a écrit dans le message de news: (...)
D'apres toi, il y a combien d'exploits locaux par rapport a des exploit remotes ? Quelque chose me dit qu'il est beaucoup plus difficile de cracker une machine via le reseau (et souvent via des programmes, voire des serveurs intermediaires) qu'en disposant d'un acces en local, quel qu'il soit.
pour avoir un acces en local il faut que tu soit sur le poste administration du serveur donc en general l'administrateur a le mot de passe root
Et c'est justement là que tu te plantes complètement. Un petit exemple valant mieux qu'un discours, voici un extrait des logs d'un serveur Web:
Ici, le ver (sur la machine distante: 138.49.132.235) tente de lancer la commande ci-dessus, qui devrait avoir pour résultat de faire un simple "dir" sur le *serveur*. Vu que la machine est sous Irix, l'arborescence "/winnt/..." n'est pas valable, et donc le serveur l'a gentiment refusée (Erreur 404).
Tu comprends mieux maintenant?
La commande lancée par la requête s'exécuterait avec les mêmes droits que le service lancé. Si celui-ci est lancé par un utilisateur ayant les droits minimaux, le risque n'est pas trop grand. Par contre, si le service est lancé en tant que root, la machine est à la merci du ver (Nimbda ou Code Rouge, je ne sais plus).
(...)
prenons un exemple toto veux pirater titi
1/ sous pick jai l'users toto en remote toto crack le remote il se trouve sous linux user toto avec les droit toto et ne peut pas en sortir il doit maintenant cracker pick ou linux pour pouvoir acceder au droit de titi
2/ sous oracle j'ai l'user toto en remote toto crack le remote toto se trouve connecter sous linux avec l'user "oracle" et a acces a tout les users d'oracle donc titi
Faux. Oracle ayant sa propore gestion des utilisateurs, toto est inconnu de Linux et ne peut donc se connecter à la machine...
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:bd3fr2-tek.ln1@gulliver.unices.org...
(...)
D'apres toi, il y a combien d'exploits locaux par rapport a des exploit
remotes ? Quelque chose me dit qu'il est beaucoup plus difficile de
cracker une machine via le reseau (et souvent via des programmes, voire
des serveurs intermediaires) qu'en disposant d'un acces en local, quel
qu'il soit.
pour avoir un acces en local il faut que tu soit sur le poste administration
du serveur donc en general l'administrateur a le mot de passe root
Et c'est justement là que tu te plantes complètement. Un petit exemple
valant mieux qu'un discours, voici un extrait des logs d'un serveur Web:
Ici, le ver (sur la machine distante: 138.49.132.235) tente de lancer la
commande ci-dessus, qui devrait avoir pour résultat de faire un simple
"dir" sur le *serveur*. Vu que la machine est sous Irix, l'arborescence
"/winnt/..." n'est pas valable, et donc le serveur l'a gentiment refusée
(Erreur 404).
Tu comprends mieux maintenant?
La commande lancée par la requête s'exécuterait avec les mêmes droits
que le service lancé. Si celui-ci est lancé par un utilisateur ayant les
droits minimaux, le risque n'est pas trop grand. Par contre, si le
service est lancé en tant que root, la machine est à la merci du ver
(Nimbda ou Code Rouge, je ne sais plus).
(...)
prenons un exemple toto veux pirater titi
1/ sous pick jai l'users toto en remote
toto crack le remote
il se trouve sous linux user toto avec les droit toto et ne peut pas en
sortir
il doit maintenant cracker pick ou linux pour pouvoir acceder au droit de
titi
2/ sous oracle j'ai l'user toto en remote
toto crack le remote
toto se trouve connecter sous linux avec l'user "oracle" et a acces a tout
les users d'oracle donc titi
Faux. Oracle ayant sa propore gestion des utilisateurs, toto est inconnu
de Linux et ne peut donc se connecter à la machine...
"Stephane TOUGARD" a écrit dans le message de news: (...)
D'apres toi, il y a combien d'exploits locaux par rapport a des exploit remotes ? Quelque chose me dit qu'il est beaucoup plus difficile de cracker une machine via le reseau (et souvent via des programmes, voire des serveurs intermediaires) qu'en disposant d'un acces en local, quel qu'il soit.
pour avoir un acces en local il faut que tu soit sur le poste administration du serveur donc en general l'administrateur a le mot de passe root
Et c'est justement là que tu te plantes complètement. Un petit exemple valant mieux qu'un discours, voici un extrait des logs d'un serveur Web:
Ici, le ver (sur la machine distante: 138.49.132.235) tente de lancer la commande ci-dessus, qui devrait avoir pour résultat de faire un simple "dir" sur le *serveur*. Vu que la machine est sous Irix, l'arborescence "/winnt/..." n'est pas valable, et donc le serveur l'a gentiment refusée (Erreur 404).
Tu comprends mieux maintenant?
La commande lancée par la requête s'exécuterait avec les mêmes droits que le service lancé. Si celui-ci est lancé par un utilisateur ayant les droits minimaux, le risque n'est pas trop grand. Par contre, si le service est lancé en tant que root, la machine est à la merci du ver (Nimbda ou Code Rouge, je ne sais plus).
(...)
prenons un exemple toto veux pirater titi
1/ sous pick jai l'users toto en remote toto crack le remote il se trouve sous linux user toto avec les droit toto et ne peut pas en sortir il doit maintenant cracker pick ou linux pour pouvoir acceder au droit de titi
2/ sous oracle j'ai l'user toto en remote toto crack le remote toto se trouve connecter sous linux avec l'user "oracle" et a acces a tout les users d'oracle donc titi
Faux. Oracle ayant sa propore gestion des utilisateurs, toto est inconnu de Linux et ne peut donc se connecter à la machine...
helios
"Stephane Zuckerman" a écrit dans le message de news:
le fait qu'un profane en sql a trouve une solution par "automate" que les
gourrous n'ont pas trouve me fait douter du niveau des dit gourrous la solution "automate" fonctionne je penses qu'elle doit etre lourde en ressources machine par rapport a un sgbdMV mais bon le critere performance
n'etait pas donnee mais dans la realite ou les bases de donnee sont reelle
la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution de départ pour développer des requêtes sur UN SGBD. Concernant la lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD utilisant SQL, tu ne peux pas réellement émettre un avis sur la performance (ou son absence) de telles requêtes. D'autant plus que cela dépendra fortement du SGBD choisi.
la question n'est pas de savoir si gui ou non c'est bon la question est
qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les gourrou de plus que le gui ?
un emulation est toujour moins performante et plus limite que l'original en matiere de programmation : un emulateur linux sous windows est moins performant et plus limite que linux or la solution fait une emulation du MV (gestion au niveau requete des separateurs de valeur) en plus l'emulation ayant des limites elle ne pourras en aucun cas geres par exemple 10 niveaux de separateur
pour un niveau il a fallu creer une table annexe pour deux il faudrait creer des tables annexe au table annexe ,pour trois des tables annexe autable annexe des table annexe.....
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0507251555090.48331@vega.utc.fr...
le fait qu'un profane en sql a trouve une solution par "automate" que
les
gourrous n'ont pas trouve me fait douter du niveau des dit gourrous
la solution "automate" fonctionne je penses qu'elle doit etre lourde en
ressources machine par rapport a un sgbdMV mais bon le critere
performance
n'etait pas donnee mais dans la realite ou les bases de donnee sont
reelle
la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et
je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution
de départ pour développer des requêtes sur UN SGBD. Concernant la
lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD
utilisant SQL, tu ne peux pas réellement émettre un avis sur la
performance (ou son absence) de telles requêtes. D'autant plus que cela
dépendra fortement du SGBD choisi.
la question n'est pas de savoir si gui ou non c'est bon la question est
qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les
gourrou de plus que le gui ?
un emulation est toujour moins performante et plus limite que l'original en
matiere de programmation : un emulateur linux sous windows est moins
performant et plus limite que linux or la solution fait une emulation du MV
(gestion au niveau requete des separateurs de valeur) en plus l'emulation
ayant des limites elle ne pourras en aucun cas geres par exemple 10 niveaux
de separateur
pour un niveau il a fallu creer une table annexe pour deux il faudrait creer
des tables annexe au table annexe ,pour trois des tables annexe autable
annexe des table annexe.....
"Stephane Zuckerman" a écrit dans le message de news:
le fait qu'un profane en sql a trouve une solution par "automate" que les
gourrous n'ont pas trouve me fait douter du niveau des dit gourrous la solution "automate" fonctionne je penses qu'elle doit etre lourde en ressources machine par rapport a un sgbdMV mais bon le critere performance
n'etait pas donnee mais dans la realite ou les bases de donnee sont reelle
la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution de départ pour développer des requêtes sur UN SGBD. Concernant la lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD utilisant SQL, tu ne peux pas réellement émettre un avis sur la performance (ou son absence) de telles requêtes. D'autant plus que cela dépendra fortement du SGBD choisi.
la question n'est pas de savoir si gui ou non c'est bon la question est
qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les gourrou de plus que le gui ?
un emulation est toujour moins performante et plus limite que l'original en matiere de programmation : un emulateur linux sous windows est moins performant et plus limite que linux or la solution fait une emulation du MV (gestion au niveau requete des separateurs de valeur) en plus l'emulation ayant des limites elle ne pourras en aucun cas geres par exemple 10 niveaux de separateur
pour un niveau il a fallu creer une table annexe pour deux il faudrait creer des tables annexe au table annexe ,pour trois des tables annexe autable annexe des table annexe.....
Jerome Lambert
Jerome Lambert wrote:
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
Jerome Lambert wrote:
En gros, oui.
Un lien un peu plus recommandable sur le bidule:
http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi
j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser
un bon vieux Shell et si vraiment on veux gerer des grosses tables en
mode clef valeurs (c'est quand meme vachement basique comme principe),
on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris
oui l'on a une cle unique par champs
plus il y a de donnees plus il y a de cles
bonjour les performance
et le dico sert a ameloirer les performances
cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut
cle n a cles n+100
coucou les trous
mais se qui me titille
il y a une limitation liee a la taille des cles
et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire
d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION
01 Jerome 12:30
02 Remy 12:45
03 Jerome 13:20
04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS
01 Jerome 12:30;13:20
02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels,
et on peut arriver au même résultat en créant des tables liées dans un
SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
Stephane TOUGARD
Jerome Lambert wrote:
Et c'est justement là que tu te plantes complètement. Un petit exemple valant mieux qu'un discours, voici un extrait des logs d'un serveur Web: ...
Faux. Oracle ayant sa propore gestion des utilisateurs, toto est inconnu de Linux et ne peut donc se connecter à la machine...
Tu sais, tu parles a un type qui connait par coeur les procedures d'installation et de maintenance d'un pseudo OS vieux de 30 ans, qui n'a jamais ete capable de se remettre en question et de suivre les differentes evolutions de l'informatique.
Il ne connait rien a rien a Unix, confond des notions pourtant basiques de l'administration systeme, raconte tout, n'importe quoi et son contraire au depit de toute logique et surtout de toute connaissance.
Peut etre que son systeme est genial ... en 1970,
-- 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 wrote:
Et c'est justement là que tu te plantes complètement. Un petit exemple
valant mieux qu'un discours, voici un extrait des logs d'un serveur Web:
...
Faux. Oracle ayant sa propore gestion des utilisateurs, toto est inconnu
de Linux et ne peut donc se connecter à la machine...
Tu sais, tu parles a un type qui connait par coeur les procedures
d'installation et de maintenance d'un pseudo OS vieux de 30 ans, qui n'a
jamais ete capable de se remettre en question et de suivre les
differentes evolutions de l'informatique.
Il ne connait rien a rien a Unix, confond des notions pourtant basiques
de l'administration systeme, raconte tout, n'importe quoi et son
contraire au depit de toute logique et surtout de toute connaissance.
Peut etre que son systeme est genial ... en 1970,
--
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
Et c'est justement là que tu te plantes complètement. Un petit exemple valant mieux qu'un discours, voici un extrait des logs d'un serveur Web: ...
Faux. Oracle ayant sa propore gestion des utilisateurs, toto est inconnu de Linux et ne peut donc se connecter à la machine...
Tu sais, tu parles a un type qui connait par coeur les procedures d'installation et de maintenance d'un pseudo OS vieux de 30 ans, qui n'a jamais ete capable de se remettre en question et de suivre les differentes evolutions de l'informatique.
Il ne connait rien a rien a Unix, confond des notions pourtant basiques de l'administration systeme, raconte tout, n'importe quoi et son contraire au depit de toute logique et surtout de toute connaissance.
Peut etre que son systeme est genial ... en 1970,
-- 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 TOUGARD
Stephane Zuckerman wrote:
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. Je pense qu'il parlait des runlevels de Linux (en System V)
Je pense qu'il donnait des chiffres au hasard pour faire son interessant.
-- 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 wrote:
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait,
ça commence au niveau 1.
Je pense qu'il parlait des runlevels de Linux (en System V)
Je pense qu'il donnait des chiffres au hasard pour faire son
interessant.
--
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
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. Je pense qu'il parlait des runlevels de Linux (en System V)
Je pense qu'il donnait des chiffres au hasard pour faire son interessant.
-- 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 TOUGARD
helios wrote:
il suffit de cracker le remote pour avoir acces a tout les utilisateur du sgbd
Il est mignon.
-- 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:
il suffit de cracker le remote pour avoir acces a tout les utilisateur du
sgbd
Il est mignon.
--
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
il suffit de cracker le remote pour avoir acces a tout les utilisateur du sgbd
Il est mignon.
-- 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
"Stephane Zuckerman" a écrit dans le message de news:
le fait qu'un profane en sql a trouve une solution par "automate" que les gourrous n'ont pas trouve me fait douter du niveau des dit gourrous la solution "automate" fonctionne je penses qu'elle doit etre lourde en ressources machine par rapport a un sgbdMV mais bon le critere performance n'etait pas donnee mais dans la realite ou les bases de donnee sont reelle la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution de départ pour développer des requêtes sur UN SGBD. Concernant la lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD utilisant SQL, tu ne peux pas réellement émettre un avis sur la performance (ou son absence) de telles requêtes. D'autant plus que cela dépendra fortement du SGBD choisi.
la question n'est pas de savoir si gui ou non c'est bon la question est qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les gourrou de plus que le gui ?
Il y a une différence: je suis très "joueur", et donc je fonce quand on me mets au défi. Il faut dire aussi qu'à l'époque où j'utilisais Access quasi quotidiennement, je programmais souvent le genre de requête que tu m'as mis au défi de réaliser. Cela m'a donc étonné que tu as affirmé que "seul Pick pouvais réaliser ce genre de chose", et j'ai donc cherché.
(...)
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0507251555090.48331@vega.utc.fr...
le fait qu'un profane en sql a trouve une solution par "automate"
que les gourrous n'ont pas trouve me fait douter du niveau des
dit gourrous la solution "automate" fonctionne je penses qu'elle
doit etre lourde en ressources machine par rapport a un sgbdMV
mais bon le critere performance n'etait pas donnee mais dans la
realite ou les bases de donnee sont reelle la solution automate
serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et
je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution
de départ pour développer des requêtes sur UN SGBD. Concernant la
lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD
utilisant SQL, tu ne peux pas réellement émettre un avis sur la
performance (ou son absence) de telles requêtes. D'autant plus que cela
dépendra fortement du SGBD choisi.
la question n'est pas de savoir si gui ou non c'est bon la question est
qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les
gourrou de plus que le gui ?
Il y a une différence: je suis très "joueur", et donc je fonce quand on
me mets au défi.
Il faut dire aussi qu'à l'époque où j'utilisais Access quasi
quotidiennement, je programmais souvent le genre de requête que tu m'as
mis au défi de réaliser.
Cela m'a donc étonné que tu as affirmé que "seul Pick pouvais réaliser
ce genre de chose", et j'ai donc cherché.
"Stephane Zuckerman" a écrit dans le message de news:
le fait qu'un profane en sql a trouve une solution par "automate" que les gourrous n'ont pas trouve me fait douter du niveau des dit gourrous la solution "automate" fonctionne je penses qu'elle doit etre lourde en ressources machine par rapport a un sgbdMV mais bon le critere performance n'etait pas donnee mais dans la realite ou les bases de donnee sont reelle la solution automate serais exclus
Quand je développe une application, je "tatonne" via des requêtes SQL, et je ne vois pas en quoi utiliser une GUI ne serait pas une bonne solution de départ pour développer des requêtes sur UN SGBD. Concernant la lourdeur, à partir du moment où tu avoues ta méconnaissance des SGBD utilisant SQL, tu ne peux pas réellement émettre un avis sur la performance (ou son absence) de telles requêtes. D'autant plus que cela dépendra fortement du SGBD choisi.
la question n'est pas de savoir si gui ou non c'est bon la question est qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les gourrou de plus que le gui ?
Il y a une différence: je suis très "joueur", et donc je fonce quand on me mets au défi. Il faut dire aussi qu'à l'époque où j'utilisais Access quasi quotidiennement, je programmais souvent le genre de requête que tu m'as mis au défi de réaliser. Cela m'a donc étonné que tu as affirmé que "seul Pick pouvais réaliser ce genre de chose", et j'ai donc cherché.
(...)
Stephane Zuckerman
la question n'est pas de savoir si gui ou non c'est bon la question est qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les gourrou de plus que le gui ?
Je me fous de tes "gourous". J'ai pas vu leur solution. Par contre, une chose est certaine, tu n'as pas compris ce que je disais. :-)
un emulation est toujour moins performante et plus limite que l'original en matiere de programmation :
Je n'ai jamais parlé d'émulation. Quand tu prends Access (par exemple), il ne s'agit nullement d'émulation : tu cliques sur des cases, etc., mais au final, ce que tu fais, c'est créer graphiquement une requête SQL. Je ne vois pas où est l'émulation là-dedans. Ce que je disais, c'est que une fois que j'ai bien calibré mes requêtes (graphiquement ou pas), je n'ai plus qu'à les mettre dans un coin, les insérer au bon moment dans mon application, et c'est tout.
performant et plus limite que linux or la solution fait une emulation du MV (gestion au niveau requete des separateurs de valeur) en plus l'emulation ayant des limites elle ne pourras en aucun cas geres par exemple 10 niveaux de separateur
Là où tu te plantes, c'est que tu crois que tous les SGBD se valent. Certains gèrent les requêtes imbriquées par exemple, et permettent donc de faire du multicritère de façon transparente. D'autres pas, et cela te force à utiliser des jointures (et donc, implicitement, à créer des tables temporaires contenant des résultats intermédiaires).
De plus, tu oublies que les SGBD utilisent un cache pour stocker les requêtes, ce qui accélère énormément les accès. Bref. Parler de "supériorité" d'un SGBD par rapport à un autre quand on ne sait pas forcément comment fonctionne "l'autre" avec lequel tu veux comparer, ça ne sert à rien.
-- "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)
la question n'est pas de savoir si gui ou non c'est bon la question est
qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les
gourrou de plus que le gui ?
Je me fous de tes "gourous". J'ai pas vu leur solution. Par contre, une
chose est certaine, tu n'as pas compris ce que je disais. :-)
un emulation est toujour moins performante et plus limite que l'original en
matiere de programmation :
Je n'ai jamais parlé d'émulation. Quand tu prends Access (par exemple), il
ne s'agit nullement d'émulation : tu cliques sur des cases, etc., mais au
final, ce que tu fais, c'est créer graphiquement une requête SQL. Je ne
vois pas où est l'émulation là-dedans. Ce que je disais, c'est que une
fois que j'ai bien calibré mes requêtes (graphiquement ou pas), je n'ai
plus qu'à les mettre dans un coin, les insérer au bon moment dans mon
application, et c'est tout.
performant et plus limite que linux or la solution fait une emulation du MV
(gestion au niveau requete des separateurs de valeur) en plus l'emulation
ayant des limites elle ne pourras en aucun cas geres par exemple 10 niveaux
de separateur
Là où tu te plantes, c'est que tu crois que tous les SGBD se valent.
Certains gèrent les requêtes imbriquées par exemple, et permettent donc de
faire du multicritère de façon transparente. D'autres pas, et cela te
force à utiliser des jointures (et donc, implicitement, à créer des tables
temporaires contenant des résultats intermédiaires).
De plus, tu oublies que les SGBD utilisent un cache pour stocker les
requêtes, ce qui accélère énormément les accès. Bref. Parler de
"supériorité" d'un SGBD par rapport à un autre quand on ne sait pas
forcément comment fonctionne "l'autre" avec lequel tu veux comparer, ça ne
sert à rien.
--
"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)
la question n'est pas de savoir si gui ou non c'est bon la question est qu'un profane avec un gui a fait mieux que les gourrous qu'apporte les gourrou de plus que le gui ?
Je me fous de tes "gourous". J'ai pas vu leur solution. Par contre, une chose est certaine, tu n'as pas compris ce que je disais. :-)
un emulation est toujour moins performante et plus limite que l'original en matiere de programmation :
Je n'ai jamais parlé d'émulation. Quand tu prends Access (par exemple), il ne s'agit nullement d'émulation : tu cliques sur des cases, etc., mais au final, ce que tu fais, c'est créer graphiquement une requête SQL. Je ne vois pas où est l'émulation là-dedans. Ce que je disais, c'est que une fois que j'ai bien calibré mes requêtes (graphiquement ou pas), je n'ai plus qu'à les mettre dans un coin, les insérer au bon moment dans mon application, et c'est tout.
performant et plus limite que linux or la solution fait une emulation du MV (gestion au niveau requete des separateurs de valeur) en plus l'emulation ayant des limites elle ne pourras en aucun cas geres par exemple 10 niveaux de separateur
Là où tu te plantes, c'est que tu crois que tous les SGBD se valent. Certains gèrent les requêtes imbriquées par exemple, et permettent donc de faire du multicritère de façon transparente. D'autres pas, et cela te force à utiliser des jointures (et donc, implicitement, à créer des tables temporaires contenant des résultats intermédiaires).
De plus, tu oublies que les SGBD utilisent un cache pour stocker les requêtes, ce qui accélère énormément les accès. Bref. Parler de "supériorité" d'un SGBD par rapport à un autre quand on ne sait pas forcément comment fonctionne "l'autre" avec lequel tu veux comparer, ça ne sert à rien.
-- "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)
