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
sans access jamais sql ne se serais implanter sur micro c'est le marketing microsoft qui a implanter access et donc sql
Mais le sql n'est jamais arrive sur micro. Madame Michu ne fait pas de SQL.
aujourd hui windows cherche a implanter les concept de pick dans son prochain windows ......
Oui enfin tu nous apprends rien, on sait deja qu'ils ont 30 ans de retard.
-- 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:
sans access jamais sql ne se serais implanter sur micro c'est le marketing
microsoft qui a implanter access et donc sql
Mais le sql n'est jamais arrive sur micro. Madame Michu ne fait pas de
SQL.
aujourd hui windows cherche a implanter les concept de pick dans son
prochain windows ......
Oui enfin tu nous apprends rien, on sait deja qu'ils ont 30 ans de
retard.
--
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
sans access jamais sql ne se serais implanter sur micro c'est le marketing microsoft qui a implanter access et donc sql
Mais le sql n'est jamais arrive sur micro. Madame Michu ne fait pas de SQL.
aujourd hui windows cherche a implanter les concept de pick dans son prochain windows ......
Oui enfin tu nous apprends rien, on sait deja qu'ils ont 30 ans de retard.
-- 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:
dans une base relationnel si par exemple un client paie une facture en plusieur fois il y a autant d' article dans le tableau que de paiement car une case ne peux avoir qu'une valeur dans une base multivalue si par exemple un client paie une facture en plusieur fois il y a un seul article dans le tableau et il contient plusieur paiement dans la case paiement
Ah c'est ca le multi-valeurs. C'est tout con a faire avec n'importe quelle SGBD, c'est juste une histoire d'index qui relie deux tables.
Ensuite les donnees avec des requetes imbriquees, rien de bien complique dans tout cela.
pour revenir a ton terme tableau chaque case fichier pick peux etre assimiler a un tableau qui peut avoir 128 dimension , simuler le fonctionnement avec des table annexe est possible mais compliquer pour 2 3 dimension en sql mais au dela la gestion des dimention est laborieuse et coute tres chers en performance alors que un system mv geres sans que le gestionnaire ai a s' en occuper le multidimention du tableau
Tu veux dire que chaque valeur dans une entree correspond chacune a plusieurs valeurs ?
Parce que si tu veux, des valeurs derriere un index, je t'en mets quelques centaines de milliers, chacune avec plusieurs definitions, ca me pose pas vraiment un probleme et ca sera tres performant.
Apres tu peux dire que c'est lent, tout ce que tu veux. Pour 90% des systemes conventionnels, un SGBD pas optimise est deja assez performant, pour 99% des cas restants, l'optimiser suffira a resoudre tous les problemes.
apres le system des dicos c'est juste le systeme du vocabulaire de requete pousser a l'extreme on peut creer du vocabulaire et creer des synonymes en fait les deux concept dico et multivaleur pourrais etre independant mais sont reunni ainsi on peut tres bien imagine un SGBDR fonctionnant par dico et un SGBDMV qui n'aurait pas de system de dico mais juste un system de requete avec un vocabulaire fixe
Un Dico ne sert strictement a rien. C'est qu'une histoire d'interface. Le SQL est un language qui permet de definir a peu pret n'importe quoi et lorqu'il ne le permet pas, on l'etend en PL/SQL (ou son homologue que se doit de proposer toute bonne base), ensuite, pour les interfaces, c'est un programme en PHP/Perl/C/C++/... qui propose a l'utilisateur final les donnees qu'il veut retrouver.
Un dico etait utile a l'epoque ou la secretaire accedait directement au mainframe, mais ce temps est revolu et la secretaire ne construit meme pas des requetes, elle clique sur le bouton "Chercher Client", elle donne les infos et elle a son client.
-- 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:
dans une base relationnel si par exemple un client paie une facture en
plusieur fois il y a autant d' article dans le tableau que de paiement car
une case ne peux avoir qu'une valeur
dans une base multivalue si par exemple un client paie une facture en
plusieur fois il y a un seul article dans le tableau et il contient plusieur
paiement dans la case paiement
Ah c'est ca le multi-valeurs. C'est tout con a faire avec n'importe
quelle SGBD, c'est juste une histoire d'index qui relie deux tables.
Ensuite les donnees avec des requetes imbriquees, rien de bien complique
dans tout cela.
pour revenir a ton terme tableau chaque case fichier pick peux etre
assimiler a un tableau qui peut avoir 128 dimension , simuler le
fonctionnement avec des table annexe est possible mais compliquer pour 2 3
dimension en sql mais au dela la gestion des dimention est laborieuse et
coute tres chers en performance alors que un system mv geres sans que le
gestionnaire ai a s' en occuper le multidimention du tableau
Tu veux dire que chaque valeur dans une entree correspond chacune a
plusieurs valeurs ?
Parce que si tu veux, des valeurs derriere un index, je t'en mets
quelques centaines de milliers, chacune avec plusieurs definitions, ca
me pose pas vraiment un probleme et ca sera tres performant.
Apres tu peux dire que c'est lent, tout ce que tu veux. Pour 90% des
systemes conventionnels, un SGBD pas optimise est deja assez performant,
pour 99% des cas restants, l'optimiser suffira a resoudre tous les
problemes.
apres le system des dicos c'est juste le systeme du vocabulaire de requete
pousser a l'extreme on peut creer du vocabulaire et creer des synonymes en
fait les deux concept dico et multivaleur pourrais etre independant mais
sont reunni ainsi on peut tres bien imagine un SGBDR fonctionnant par dico
et un SGBDMV qui n'aurait pas de system de dico mais juste un system de
requete avec un vocabulaire fixe
Un Dico ne sert strictement a rien. C'est qu'une histoire d'interface.
Le SQL est un language qui permet de definir a peu pret n'importe quoi
et lorqu'il ne le permet pas, on l'etend en PL/SQL (ou son homologue que
se doit de proposer toute bonne base), ensuite, pour les interfaces,
c'est un programme en PHP/Perl/C/C++/... qui propose a l'utilisateur
final les donnees qu'il veut retrouver.
Un dico etait utile a l'epoque ou la secretaire accedait directement au
mainframe, mais ce temps est revolu et la secretaire ne construit meme
pas des requetes, elle clique sur le bouton "Chercher Client", elle
donne les infos et elle a son client.
--
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
dans une base relationnel si par exemple un client paie une facture en plusieur fois il y a autant d' article dans le tableau que de paiement car une case ne peux avoir qu'une valeur dans une base multivalue si par exemple un client paie une facture en plusieur fois il y a un seul article dans le tableau et il contient plusieur paiement dans la case paiement
Ah c'est ca le multi-valeurs. C'est tout con a faire avec n'importe quelle SGBD, c'est juste une histoire d'index qui relie deux tables.
Ensuite les donnees avec des requetes imbriquees, rien de bien complique dans tout cela.
pour revenir a ton terme tableau chaque case fichier pick peux etre assimiler a un tableau qui peut avoir 128 dimension , simuler le fonctionnement avec des table annexe est possible mais compliquer pour 2 3 dimension en sql mais au dela la gestion des dimention est laborieuse et coute tres chers en performance alors que un system mv geres sans que le gestionnaire ai a s' en occuper le multidimention du tableau
Tu veux dire que chaque valeur dans une entree correspond chacune a plusieurs valeurs ?
Parce que si tu veux, des valeurs derriere un index, je t'en mets quelques centaines de milliers, chacune avec plusieurs definitions, ca me pose pas vraiment un probleme et ca sera tres performant.
Apres tu peux dire que c'est lent, tout ce que tu veux. Pour 90% des systemes conventionnels, un SGBD pas optimise est deja assez performant, pour 99% des cas restants, l'optimiser suffira a resoudre tous les problemes.
apres le system des dicos c'est juste le systeme du vocabulaire de requete pousser a l'extreme on peut creer du vocabulaire et creer des synonymes en fait les deux concept dico et multivaleur pourrais etre independant mais sont reunni ainsi on peut tres bien imagine un SGBDR fonctionnant par dico et un SGBDMV qui n'aurait pas de system de dico mais juste un system de requete avec un vocabulaire fixe
Un Dico ne sert strictement a rien. C'est qu'une histoire d'interface. Le SQL est un language qui permet de definir a peu pret n'importe quoi et lorqu'il ne le permet pas, on l'etend en PL/SQL (ou son homologue que se doit de proposer toute bonne base), ensuite, pour les interfaces, c'est un programme en PHP/Perl/C/C++/... qui propose a l'utilisateur final les donnees qu'il veut retrouver.
Un dico etait utile a l'epoque ou la secretaire accedait directement au mainframe, mais ce temps est revolu et la secretaire ne construit meme pas des requetes, elle clique sur le bouton "Chercher Client", elle donne les infos et elle a son client.
-- 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
stanislas.kertanguyde
helios wrote:
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé plus un individue est inteligent plus il arrives a comprendre une communication avec un taux d'antropie important .
Vous confondez *E*ntropie et alcoolémie.
Ou alors vous avez lu, à l'envers, "La théorie de l'information pour les nuls".
-- inversez "kertanguy" et "de" pour me joindre
helios <helios@com02.com> wrote:
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé
plus un individue est inteligent plus il arrives a comprendre une
communication avec un taux d'antropie important .
Vous confondez *E*ntropie et alcoolémie.
Ou alors vous avez lu, à l'envers, "La théorie de l'information pour les
nuls".
je te conseil la lecture sur l'antropie et apres tu comprendras , en resumé plus un individue est inteligent plus il arrives a comprendre une communication avec un taux d'antropie important .
Vous confondez *E*ntropie et alcoolémie.
Ou alors vous avez lu, à l'envers, "La théorie de l'information pour les nuls".
-- inversez "kertanguy" et "de" pour me joindre
helios
"Stephane TOUGARD" a écrit dans le message de news:
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,
--
je suis administrateur unix aussi
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:hbcfr2-4hl.ln1@gulliver.unices.org...
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.
"Stephane TOUGARD" a écrit dans le message de news:
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,
--
je suis administrateur unix aussi
Patrik
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.
Niveau 0 de l'OSI .... Bon, alors c'est stocké directement dans le
hardware de la carte réseau, du cable .... ?
Alors, pourquoi faut-il un OS pour le faire fonctionner ?
Comprends pas tout, moi .... ;-)
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.
Niveau 0 de l'OSI .... Bon, alors c'est stocké directement dans le
hardware de la carte réseau, du cable .... ?
Alors, pourquoi faut-il un OS pour le faire fonctionner ?
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.
Niveau 0 de l'OSI .... Bon, alors c'est stocké directement dans le
hardware de la carte réseau, du cable .... ?
Alors, pourquoi faut-il un OS pour le faire fonctionner ?
Comprends pas tout, moi .... ;-)
helios
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
c'est l'utilisateur oracle qui est connu et l'utilisateur oracle a acces au
fichier de toto de titi et tout les autre donc une fois crack le remote toto
on se retrouve avec l'acces au fichier de l'ensemble des users oracle tandis
que sous pick un crack le remote on a acces qu'au fichier de toto
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a ses fichiers comme Unix et l'acces multi-utilisateur est gere par un systeme de securite type ACL.
t'as encore rien compris chaque utilisateur a des droit sur des fichier et appli pas sur tout la base de donne ainsi pourquoi un commercial aurait il acces a la gestion fournisseur complete ou au fiche de paye , pourquoi le technicien paye a la gestion ....avec oracle il suffit de craque le technicien paye pour avoir acces a toute les donnes de l'entreprise tandis que sous pick si tu crack la paie tu acces qu'a la paie
Ces vieux systemes obsoletes embarquent souvent un modele de securite assez eleve au niveau de la gestion des Users.
il y a jamais trop de securite
En fait, ca parle quand meme avec un process en root, parce qu'il faut bien emuler le mecanisme au dessus de la couche Unix, mais c'est relativement invisible.
Enfin bon, rien qui justifie que ca tourne en root, si ce n'est que la table user systeme et la table user pick sont melanges.
Bref, c'est crade et vraiment pas safe.
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:5o8gr2-h1o.ln1@gulliver.unices.org...
helios wrote:
c'est l'utilisateur oracle qui est connu et l'utilisateur oracle a acces
au
fichier de toto de titi et tout les autre donc une fois crack le remote
toto
on se retrouve avec l'acces au fichier de l'ensemble des users oracle
tandis
que sous pick un crack le remote on a acces qu'au fichier de toto
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a
ses fichiers comme Unix et l'acces multi-utilisateur est gere par un
systeme de securite type ACL.
t'as encore rien compris chaque utilisateur a des droit sur des fichier et
appli pas sur tout la base de donne ainsi pourquoi un commercial aurait il
acces a la gestion fournisseur complete ou au fiche de paye , pourquoi le
technicien paye a la gestion ....avec oracle il suffit de craque le
technicien paye pour avoir acces a toute les donnes de l'entreprise tandis
que sous pick si tu crack la paie tu acces qu'a la paie
Ces vieux systemes obsoletes embarquent souvent un modele de securite
assez eleve au niveau de la gestion des Users.
il y a jamais trop de securite
En fait, ca parle quand meme avec un process en root, parce qu'il faut
bien emuler le mecanisme au dessus de la couche Unix, mais c'est
relativement invisible.
Enfin bon, rien qui justifie que ca tourne en root, si ce n'est que la
table user systeme et la table user pick sont melanges.
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
c'est l'utilisateur oracle qui est connu et l'utilisateur oracle a acces au
fichier de toto de titi et tout les autre donc une fois crack le remote toto
on se retrouve avec l'acces au fichier de l'ensemble des users oracle tandis
que sous pick un crack le remote on a acces qu'au fichier de toto
Ho, j'ai compris, Pick n'est pas multi-utilisateur, chaque utilisateur a ses fichiers comme Unix et l'acces multi-utilisateur est gere par un systeme de securite type ACL.
t'as encore rien compris chaque utilisateur a des droit sur des fichier et appli pas sur tout la base de donne ainsi pourquoi un commercial aurait il acces a la gestion fournisseur complete ou au fiche de paye , pourquoi le technicien paye a la gestion ....avec oracle il suffit de craque le technicien paye pour avoir acces a toute les donnes de l'entreprise tandis que sous pick si tu crack la paie tu acces qu'a la paie
Ces vieux systemes obsoletes embarquent souvent un modele de securite assez eleve au niveau de la gestion des Users.
il y a jamais trop de securite
En fait, ca parle quand meme avec un process en root, parce qu'il faut bien emuler le mecanisme au dessus de la couche Unix, mais c'est relativement invisible.
Enfin bon, rien qui justifie que ca tourne en root, si ce n'est que la table user systeme et la table user pick sont melanges.
Bref, c'est crade et vraiment pas safe.
talon
Thierry Thomas wrote:
Lundi 25 juillet 2005 à 17:02 GMT, Michel Talon a écrit :
Je croyais que access c'était la base que Microsoft a achetée à Sybase, auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version 10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage
Ah bon, je n'avais pas rêvé! Evidemment je parlais du serveur de base de données de Microsoft.
Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à Oracle...
Je n'ai pas entendu dire ça. J'ai entendu dire que Oracle était surtout trés fort pour vendre des produits non encore développés.
Thierry Thomas <tthomas@mail.dotcom.fr> wrote:
Lundi 25 juillet 2005 à 17:02 GMT, Michel Talon a écrit :
Je croyais que access c'était la base que Microsoft a achetée à Sybase,
auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version
10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage
Ah bon, je n'avais pas rêvé! Evidemment je parlais du serveur de base de
données de Microsoft.
Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à
Oracle...
Je n'ai pas entendu dire ça. J'ai entendu dire que Oracle était surtout
trés fort pour vendre des produits non encore développés.
Lundi 25 juillet 2005 à 17:02 GMT, Michel Talon a écrit :
Je croyais que access c'était la base que Microsoft a achetée à Sybase, auquel cas elle serait du même niveau de qualité que Oracle.
C'est MS-SQL Server qui provient de Sybase (je crois que la version 10.0.x de Sybase correspondait exactement à MS SQL 4.x). Le langage
Ah bon, je n'avais pas rêvé! Evidemment je parlais du serveur de base de données de Microsoft.
Quoiqu'il en soit, Sybase a toujours été à la traine par rapport à Oracle...
Je n'ai pas entendu dire ça. J'ai entendu dire que Oracle était surtout trés fort pour vendre des produits non encore développés.
helios
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
justement c'est la la faille il suffit de planter le process commun pour avoir acces a tout les fichiers de la base
Tout comme pick, il suffit de planter le process commun. Sauf que pick tourne en root.
la difference est que pick etant sous root il est vraiment securise et un plantage pick plante root en general donc ... tandis que le plantage du pross commun laisse acces a toute le sgbd et ce qui interresee le pirate c'est pas l'acces root mais les donnees
et la cascade de process fait perdre enormement de puissance de calcul
Ca fait perdre rien du tout, tu fais une requete a un serveur, le serveur comprend la requete et te retourne le resultat. Le temps perdu par les
couches protocolaires est derisoire, par contre le gain en convivialite, en securite et en portabilite sont phenomenales.
oracle ne tient pas la route fasse a universe peut importe ou est le manque de performance, essais de remplacement fait en 2002 , oracle a ecroule les calculateur la ou universe utilise meme pas 10% de la puissance de calcul
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd
etait de maniere marginal dans mon parc )
Qu'est ce que tu as du en faire chier comme monde.
plutot c'est moi qui me suis fait chier car cela n'a rien d'interressant
comme job et pourtant j'avait automatiser pas mal de taches merdique de securite locale (personne ne voulait faire ce boulot de con par contre cela m'a permis d'avoir de nombreuse formation de mon choix)
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:dv8gr2-h1o.ln1@gulliver.unices.org...
helios wrote:
justement c'est la la faille il suffit de planter le process commun pour
avoir acces a tout les fichiers de la base
Tout comme pick, il suffit de planter le process commun. Sauf que pick
tourne en root.
la difference est que pick etant sous root il est vraiment securise et un
plantage pick plante root en general donc ...
tandis que le plantage du pross commun laisse acces a toute le sgbd et ce
qui interresee le pirate c'est pas l'acces root mais les donnees
et la cascade de process fait perdre enormement de puissance de calcul
Ca fait perdre rien du tout, tu fais une requete a un serveur, le
serveur comprend la requete et te retourne le resultat. Le temps perdu par
les
couches protocolaires est derisoire, par contre le gain en convivialite,
en securite et en portabilite sont phenomenales.
oracle ne tient pas la route fasse a universe peut importe ou est le manque
de performance, essais de remplacement fait en 2002 , oracle a ecroule les
calculateur la ou universe utilise meme pas 10% de la puissance de calcul
en matiere de securite je vous signale que la securite local d'un centre
de
calcul france telecom etait mon job pendant 3ans j'avais 5000
utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que
pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos
sgbd
etait de maniere marginal dans mon parc )
Qu'est ce que tu as du en faire chier comme monde.
plutot c'est moi qui me suis fait chier car cela n'a rien d'interressant
comme job et pourtant j'avait automatiser pas mal de taches merdique de
securite locale (personne ne voulait faire ce boulot de con par contre cela
m'a permis d'avoir de nombreuse formation de mon choix)
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
justement c'est la la faille il suffit de planter le process commun pour avoir acces a tout les fichiers de la base
Tout comme pick, il suffit de planter le process commun. Sauf que pick tourne en root.
la difference est que pick etant sous root il est vraiment securise et un plantage pick plante root en general donc ... tandis que le plantage du pross commun laisse acces a toute le sgbd et ce qui interresee le pirate c'est pas l'acces root mais les donnees
et la cascade de process fait perdre enormement de puissance de calcul
Ca fait perdre rien du tout, tu fais une requete a un serveur, le serveur comprend la requete et te retourne le resultat. Le temps perdu par les
couches protocolaires est derisoire, par contre le gain en convivialite, en securite et en portabilite sont phenomenales.
oracle ne tient pas la route fasse a universe peut importe ou est le manque de performance, essais de remplacement fait en 2002 , oracle a ecroule les calculateur la ou universe utilise meme pas 10% de la puissance de calcul
en matiere de securite je vous signale que la securite local d'un centre de
calcul france telecom etait mon job pendant 3ans j'avais 5000 utilisateurs
et 25 serveurs repartie sur toute la france alors si je vous dit que pick
est securise mieux que vos sgbd je sait peux etre ce que je dit (vos sgbd
etait de maniere marginal dans mon parc )
Qu'est ce que tu as du en faire chier comme monde.
plutot c'est moi qui me suis fait chier car cela n'a rien d'interressant
comme job et pourtant j'avait automatiser pas mal de taches merdique de securite locale (personne ne voulait faire ce boulot de con par contre cela m'a permis d'avoir de nombreuse formation de mon choix)
Guillaume
Patrik a wroté :
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)
Niveau 0 de l'OSI .... Bon, alors c'est stocké directement dans le
hardware de la carte réseau, du cable .... ?
Alors, pourquoi faut-il un OS pour le faire fonctionner ?
Comprends pas tout, moi .... ;-)
Mitoo. Ce que j'aimerais bien qu'il m'explique, c'est comment marche le runlevel 7 en Sstem V ! >:-]
-- Guillaume
Patrik a wroté :
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)
Niveau 0 de l'OSI .... Bon, alors c'est stocké directement dans le
hardware de la carte réseau, du cable .... ?
Alors, pourquoi faut-il un OS pour le faire fonctionner ?
Comprends pas tout, moi .... ;-)
Mitoo.
Ce que j'aimerais bien qu'il m'explique, c'est comment marche le
runlevel 7 en Sstem V ! >:-]
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)
Niveau 0 de l'OSI .... Bon, alors c'est stocké directement dans le
hardware de la carte réseau, du cable .... ?
Alors, pourquoi faut-il un OS pour le faire fonctionner ?
Comprends pas tout, moi .... ;-)
Mitoo. Ce que j'aimerais bien qu'il m'explique, c'est comment marche le runlevel 7 en Sstem V ! >:-]
-- Guillaume
helios
Pour arriver a comprendre un texte que meme l'auteur ne peut pas comprendre parce qu'il a ecrit tout simplement n'importe quoi (je suis l'auteur), c'est vrai que ca doit etre une sacre antropie dans ton cerveau.
pense tu vraiment avoir ecrit n'importe quoi ? les theoricien du language te demontrerais que ton n'importe quoi est en realite une reponse dans le sujet avec juste une antropie forte et que que le cerveau humain ne connait pas le hasard donc le n'importe quoi a une logique perturber par l'antropie
ainsi si tu demande a quelqu'un un nombre entre 0 et 100 au hasard et que tu l'oblige a te donner ce que signifie ce nombre pour lui la personne a toujour une reponse alors que si le nombre etait au hasard veritablement cela serai rarement le cas
Pour arriver a comprendre un texte que meme l'auteur ne peut pas
comprendre parce qu'il a ecrit tout simplement n'importe quoi (je suis
l'auteur), c'est vrai que ca doit etre une sacre antropie dans ton
cerveau.
pense tu vraiment avoir ecrit n'importe quoi ? les theoricien du language te
demontrerais que ton n'importe quoi est en realite une reponse dans le sujet
avec juste une antropie forte et que que le cerveau humain ne connait pas le
hasard donc le n'importe quoi a une logique perturber par l'antropie
ainsi si tu demande a quelqu'un un nombre entre 0 et 100 au hasard et que tu
l'oblige a te donner ce que signifie ce nombre pour lui la personne a
toujour une reponse alors que si le nombre etait au hasard veritablement
cela serai rarement le cas
Pour arriver a comprendre un texte que meme l'auteur ne peut pas comprendre parce qu'il a ecrit tout simplement n'importe quoi (je suis l'auteur), c'est vrai que ca doit etre une sacre antropie dans ton cerveau.
pense tu vraiment avoir ecrit n'importe quoi ? les theoricien du language te demontrerais que ton n'importe quoi est en realite une reponse dans le sujet avec juste une antropie forte et que que le cerveau humain ne connait pas le hasard donc le n'importe quoi a une logique perturber par l'antropie
ainsi si tu demande a quelqu'un un nombre entre 0 et 100 au hasard et que tu l'oblige a te donner ce que signifie ce nombre pour lui la personne a toujour une reponse alors que si le nombre etait au hasard veritablement cela serai rarement le cas
