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
sauf si ton SGBD a tout les privilege de UNIX et en a toute les fonctions car est lui meme un systeme d'exploitation complet gestion users gestion peripherique gestion securite du serveur
Et il en est fier le couillon.
Un SGBD est un SGBD, pas un gestionnaire d'imprimante. Si je veux un gestionnaire d'imprimante, j'utilise lpd et on en parle plus.
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un systeme d'exploitation, fais un systeme d'exploitation.
En attendant, je laisserai pas tourner un tel trou de securite potentiel (et sans doute reel) sur ma machine ni sur aucun de mes serveurs (puis comme de toutes facons, il y a pas d'interpreteur SQL et pas de connecteur vers Perl/PHP, je vois meme pas l'interet de la chose).
-- 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:
sauf si ton SGBD a tout les privilege de UNIX et en a toute les fonctions
car est lui meme un systeme d'exploitation complet gestion users gestion
peripherique gestion securite du serveur
Et il en est fier le couillon.
Un SGBD est un SGBD, pas un gestionnaire d'imprimante. Si je veux un
gestionnaire d'imprimante, j'utilise lpd et on en parle plus.
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a
un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un
systeme d'exploitation, fais un systeme d'exploitation.
En attendant, je laisserai pas tourner un tel trou de securite potentiel
(et sans doute reel) sur ma machine ni sur aucun de mes serveurs (puis
comme de toutes facons, il y a pas d'interpreteur SQL et pas de
connecteur vers Perl/PHP, je vois meme pas l'interet de la chose).
--
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
sauf si ton SGBD a tout les privilege de UNIX et en a toute les fonctions car est lui meme un systeme d'exploitation complet gestion users gestion peripherique gestion securite du serveur
Et il en est fier le couillon.
Un SGBD est un SGBD, pas un gestionnaire d'imprimante. Si je veux un gestionnaire d'imprimante, j'utilise lpd et on en parle plus.
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un systeme d'exploitation, fais un systeme d'exploitation.
En attendant, je laisserai pas tourner un tel trou de securite potentiel (et sans doute reel) sur ma machine ni sur aucun de mes serveurs (puis comme de toutes facons, il y a pas d'interpreteur SQL et pas de connecteur vers Perl/PHP, je vois meme pas l'interet de la chose).
-- 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
JustMe wrote:
Il n'y a aucune raison pour qu'un base de donnees necessite les droits root pour tourner.
Pour pouvoir ouvrir un port privilégie ? Et ca peut marcher sans
Et il n'y a aucune raison pour qu'un SGBD tourne sur un port privilegie.
-- 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
JustMe wrote:
Il n'y a aucune raison pour qu'un base de donnees necessite les droits
root pour tourner.
Pour pouvoir ouvrir un port privilégie ? Et ca peut marcher sans
Et il n'y a aucune raison pour qu'un SGBD tourne sur un port privilegie.
--
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 n'y a aucune raison pour qu'un base de donnees necessite les droits root pour tourner.
Pour pouvoir ouvrir un port privilégie ? Et ca peut marcher sans
Et il n'y a aucune raison pour qu'un SGBD tourne sur un port privilegie.
-- 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:
pick a 6million d'utilisateurs donc plus que la majorite sinon la totalite des sgbdr je parle d'utilisateur reel pas de nombre de mec qui on une base sur leur pc c'est a dire des mecs qui on au moins plusieur GO de donnees gerer
T'as un lien, parce que j'ai l'impression qu'Oracle et MySQL sont pas au courant.
-- 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:
pick a 6million d'utilisateurs donc plus que la majorite sinon la totalite
des sgbdr je parle d'utilisateur reel pas de nombre de mec qui on une base
sur leur pc c'est a dire des mecs qui on au moins plusieur GO de donnees
gerer
T'as un lien, parce que j'ai l'impression qu'Oracle et MySQL sont pas au
courant.
--
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
pick a 6million d'utilisateurs donc plus que la majorite sinon la totalite des sgbdr je parle d'utilisateur reel pas de nombre de mec qui on une base sur leur pc c'est a dire des mecs qui on au moins plusieur GO de donnees gerer
T'as un lien, parce que j'ai l'impression qu'Oracle et MySQL sont pas au courant.
-- 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
(...)
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un systeme d'exploitation, fais un systeme d'exploitation.
"6.1 - Description du système Pick
Le système PICK est à la fois, à l'origine, un système d'exploitation multi utilisateurs et un système d'organisation du stockage des données. Il date de 1965 et fête cette année son 40e anniversaire. Cette longévité, qui pourrait passer pour une pérennité, ne doit pas faire illusion : le faible nombre d'utilisateurs d'un tel système à travers le monde, comme sa décrue dans un univers l'informatique en forte expansion, le condamne à terme.
Pour comprendre son obsolescence et par conséquent les risques inhérents à sa disparition, il faut en expliquer la structure et le fonctionnement afin de voir pourquoi il ne répond plus aux principales attentes du marché informatique.
En fait Pick fait partie de cette famille de produit comme Prologue qui mélangeait à la fois l'OS (operating System) et la gestion des données (organisation, accès, stockage). Ces systèmes sont aujourd'hui en voie de disparition."
La suite ici: <http://groups.google.fr/group/fr.comp.applications.sgbd/msg/bc6c87b13b900a0c?hl=fr&>
(...)
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a
un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un
systeme d'exploitation, fais un systeme d'exploitation.
"6.1 - Description du système Pick
Le système PICK est à la fois, à l'origine, un système d'exploitation
multi utilisateurs et un système d'organisation du stockage des données.
Il date de 1965 et fête cette année son 40e anniversaire. Cette
longévité, qui pourrait passer pour une pérennité, ne doit pas faire
illusion : le faible nombre d'utilisateurs d'un tel système à travers le
monde, comme sa décrue dans un univers l'informatique en forte
expansion, le condamne à terme.
Pour comprendre son obsolescence et par conséquent les risques inhérents
à sa disparition, il faut en expliquer la structure et le fonctionnement
afin de voir pourquoi il ne répond plus aux principales attentes du
marché informatique.
En fait Pick fait partie de cette famille de produit comme Prologue qui
mélangeait à la fois l'OS (operating System) et la gestion des données
(organisation, accès, stockage). Ces systèmes sont aujourd'hui en voie
de disparition."
La suite ici:
<http://groups.google.fr/group/fr.comp.applications.sgbd/msg/bc6c87b13b900a0c?hl=fr&>
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un systeme d'exploitation, fais un systeme d'exploitation.
"6.1 - Description du système Pick
Le système PICK est à la fois, à l'origine, un système d'exploitation multi utilisateurs et un système d'organisation du stockage des données. Il date de 1965 et fête cette année son 40e anniversaire. Cette longévité, qui pourrait passer pour une pérennité, ne doit pas faire illusion : le faible nombre d'utilisateurs d'un tel système à travers le monde, comme sa décrue dans un univers l'informatique en forte expansion, le condamne à terme.
Pour comprendre son obsolescence et par conséquent les risques inhérents à sa disparition, il faut en expliquer la structure et le fonctionnement afin de voir pourquoi il ne répond plus aux principales attentes du marché informatique.
En fait Pick fait partie de cette famille de produit comme Prologue qui mélangeait à la fois l'OS (operating System) et la gestion des données (organisation, accès, stockage). Ces systèmes sont aujourd'hui en voie de disparition."
La suite ici: <http://groups.google.fr/group/fr.comp.applications.sgbd/msg/bc6c87b13b900a0c?hl=fr&>
Vincent Bernat
OoO En cette nuit nuageuse du lundi 25 juillet 2005, vers 01:16, Stephane TOUGARD disait:
Avant tout, je vais t'apprendre quelque chose, ca va peut etre te choquer, mais c'est comme ca. SQL n'est pas un programme, c'est un language. Rien de plus. C'est un language qui permet de faire des requetes avec un SGBD qui lui meme n'est pas SQL, c'est un SGBD.
Et généralement, le SGBD vient avec un langage de programmation pour compléter les « carences » de SQL. -- BOFH excuse #407: Route flapping at the NAP.
OoO En cette nuit nuageuse du lundi 25 juillet 2005, vers 01:16,
Stephane TOUGARD <stephane@unices.org> disait:
Avant tout, je vais t'apprendre quelque chose, ca va peut etre te
choquer, mais c'est comme ca. SQL n'est pas un programme, c'est un
language. Rien de plus. C'est un language qui permet de faire des
requetes avec un SGBD qui lui meme n'est pas SQL, c'est un SGBD.
Et généralement, le SGBD vient avec un langage de programmation pour
compléter les « carences » de SQL.
--
BOFH excuse #407:
Route flapping at the NAP.
OoO En cette nuit nuageuse du lundi 25 juillet 2005, vers 01:16, Stephane TOUGARD disait:
Avant tout, je vais t'apprendre quelque chose, ca va peut etre te choquer, mais c'est comme ca. SQL n'est pas un programme, c'est un language. Rien de plus. C'est un language qui permet de faire des requetes avec un SGBD qui lui meme n'est pas SQL, c'est un SGBD.
Et généralement, le SGBD vient avec un langage de programmation pour compléter les « carences » de SQL. -- BOFH excuse #407: Route flapping at the NAP.
helios
exemple si je creer l'utilisateur toto sous PostgreSQL est ce que je peux
faire une connection linux avec toto comme users ?
Bien heureusement non. le message suivant dis le contraire
Il me semble avoir entendu quelque part qu'une des bases de la sécurité, c'est la séparation des privilèges... Un utilisateur applicatif n'est pas et ne doit surtout pas être équivalent à un utilisateur système. Quand tu te connecte à un site en ligne, ça te donne un accès à un shell sur le serveur ? Non.
pas la separation la gestion ainsi sauf erreur ton utilisateur applicatif
passe par unix pour ce connecter puisque ta sgbd ne sait pas gerer un utilisateur systeme et a donc besoin d'avoir un utilisateur system qu'est ce qui enpeche un "pirate" de sortir ou ne pas rentrer dans le sgbd pour hacker linux ? tandis que sous pick il n'a pas le choix il entre directement dans pick et ne peut sortir que deconnecter. sauf si c'est pick la sgbd et que l'administrateur a decider d'autorise root au connecte
si tu cree toto sous pick toto peux se connecter sous linux suivant les droit et avec le password que tu lui a creer sous pick
bien entendu l'utilisateur toto n'existait pas sous linux avant sa creation
dans le sgbd
Ca n'est pas rassurant. C'est même plutôt un bug, à moins que la base de donnée ne soit le seul programme autorisé à tourner sur le serveur. Il n'y a pas d'étanchéité entre la base et le système donc quiconque corromps la base peut foutre tout le système par terre. Fabuleux !
il y a yune difference entre l'administration et les donnees tu peux flingue ta base de donne sans corrompre le systeme d'utilisateur et
peripherique par contre dans les sgbd ou il faut un utilisateur system avant de se connecter tu peux flinguer tout avant meme d'entrer dans le sgbd , n'importe qui a acces au system d'exploitation c'est vachement securise comme truc il suffit de taper su et vogue le pirate
exemple si je creer l'utilisateur toto sous PostgreSQL est ce que je
peux
faire une connection linux avec toto comme users ?
Bien heureusement non.
le message suivant dis le contraire
Il me semble avoir entendu quelque part qu'une des bases de la sécurité,
c'est la séparation des privilèges...
Un utilisateur applicatif n'est pas et ne doit surtout pas être
équivalent à un utilisateur système.
Quand tu te connecte à un site en ligne, ça te donne un accès à un
shell sur le serveur ? Non.
pas la separation la gestion ainsi sauf erreur ton utilisateur applicatif
passe par unix pour ce connecter puisque ta sgbd ne sait pas gerer un
utilisateur systeme et a donc besoin d'avoir un utilisateur system
qu'est ce qui enpeche un "pirate" de sortir ou ne pas rentrer dans le sgbd
pour hacker linux ? tandis que sous pick il n'a pas le choix il entre
directement dans pick et ne peut sortir que deconnecter.
sauf si c'est pick la sgbd et que l'administrateur a decider d'autorise root
au connecte
si tu cree toto sous pick toto peux se connecter sous linux suivant les
droit et avec le password que tu lui a creer sous pick
bien entendu l'utilisateur toto n'existait pas sous linux avant sa
creation
dans le sgbd
Ca n'est pas rassurant. C'est même plutôt un bug, à moins que la base de
donnée ne soit le seul programme autorisé à tourner sur le serveur.
Il n'y a pas d'étanchéité entre la base et le système donc quiconque
corromps la base peut foutre tout le système par terre.
Fabuleux !
il y a yune difference entre l'administration et les donnees tu peux
flingue ta base de donne sans corrompre le systeme d'utilisateur et
peripherique par contre dans les sgbd ou il faut un utilisateur system avant
de se connecter tu peux flinguer tout avant meme d'entrer dans le sgbd ,
n'importe qui a acces au system d'exploitation c'est vachement securise
comme truc il suffit de taper su et vogue le pirate
exemple si je creer l'utilisateur toto sous PostgreSQL est ce que je peux
faire une connection linux avec toto comme users ?
Bien heureusement non. le message suivant dis le contraire
Il me semble avoir entendu quelque part qu'une des bases de la sécurité, c'est la séparation des privilèges... Un utilisateur applicatif n'est pas et ne doit surtout pas être équivalent à un utilisateur système. Quand tu te connecte à un site en ligne, ça te donne un accès à un shell sur le serveur ? Non.
pas la separation la gestion ainsi sauf erreur ton utilisateur applicatif
passe par unix pour ce connecter puisque ta sgbd ne sait pas gerer un utilisateur systeme et a donc besoin d'avoir un utilisateur system qu'est ce qui enpeche un "pirate" de sortir ou ne pas rentrer dans le sgbd pour hacker linux ? tandis que sous pick il n'a pas le choix il entre directement dans pick et ne peut sortir que deconnecter. sauf si c'est pick la sgbd et que l'administrateur a decider d'autorise root au connecte
si tu cree toto sous pick toto peux se connecter sous linux suivant les droit et avec le password que tu lui a creer sous pick
bien entendu l'utilisateur toto n'existait pas sous linux avant sa creation
dans le sgbd
Ca n'est pas rassurant. C'est même plutôt un bug, à moins que la base de donnée ne soit le seul programme autorisé à tourner sur le serveur. Il n'y a pas d'étanchéité entre la base et le système donc quiconque corromps la base peut foutre tout le système par terre. Fabuleux !
il y a yune difference entre l'administration et les donnees tu peux flingue ta base de donne sans corrompre le systeme d'utilisateur et
peripherique par contre dans les sgbd ou il faut un utilisateur system avant de se connecter tu peux flinguer tout avant meme d'entrer dans le sgbd , n'importe qui a acces au system d'exploitation c'est vachement securise comme truc il suffit de taper su et vogue le pirate
helios
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
tes utilisateurs postgreSQL peuvent se connecter linux ?
Bien sur que non (sauf si c'est voulu, mais en fait, il y a pas de lien de cause a effet).
exemple si je creer l'utilisateur toto sous PostgreSQL est ce que je peux
faire une connection linux avec toto comme users ?
Bien sur que oui.
met toi d'accord avec le precedent il dit le contraire
si tu cree toto sous pick toto peux se connecter sous linux suivant les droit et avec le password que tu lui a creer sous pick
Ben ca va, comme trou de securite c'est pas trop majeur. Il y a plus qu'a lui donner les droits root aussi a l'utilisateur, comme ca tout le sera content.
mais on peut lui donner les droits root , d'ailleur root est un utilisateur de pick
bien entendu l'utilisateur toto n'existait pas sous linux avant sa creation
dans le sgbd
Mais quelle bouse. Tu peux continuer a nous en parler, ca me subjugue un tel niveau d'insecurite.
justement pick est plus securise qu' une base sql car il geres la securite lui jusqu'a celle du system tandis que avec les base sql il faut se
connecter sous un users system avant d'etre dans le sgbd donc rien n'empeche de sortir ou ne pas rentrer dans le sgbd et de faire un su et vogue le pirate tandis que sous pick on n'a pas le choix l'utilisateur lambda rentre dans pick et ne peux en sortir que deconnecter a aucun moment un acces a linux n'est possible si cela n'a pas pas ete prevus
-- 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@unices.org> a écrit dans le message de
news:8vmdr2-3kb.ln1@gulliver.unices.org...
helios wrote:
tes utilisateurs postgreSQL peuvent se connecter linux ?
Bien sur que non (sauf si c'est voulu, mais en fait, il y a pas de lien
de cause a effet).
exemple si je creer l'utilisateur toto sous PostgreSQL est ce que je
peux
faire une connection linux avec toto comme users ?
Bien sur que oui.
met toi d'accord avec le precedent il dit le contraire
si tu cree toto sous pick toto peux se connecter sous linux suivant les
droit et avec le password que tu lui a creer sous pick
Ben ca va, comme trou de securite c'est pas trop majeur. Il y a plus
qu'a lui donner les droits root aussi a l'utilisateur, comme ca tout le
sera content.
mais on peut lui donner les droits root , d'ailleur root est un utilisateur
de pick
bien entendu l'utilisateur toto n'existait pas sous linux avant sa
creation
dans le sgbd
Mais quelle bouse. Tu peux continuer a nous en parler, ca me subjugue un
tel niveau d'insecurite.
justement pick est plus securise qu' une base sql car il geres la securite
lui jusqu'a celle du system tandis que avec les base sql il faut se
connecter sous un users system avant d'etre dans le sgbd donc rien n'empeche
de sortir ou ne pas rentrer dans le sgbd et de faire un su et vogue le
pirate tandis que sous pick on n'a pas le choix l'utilisateur lambda rentre
dans pick et ne peux en sortir que deconnecter
a aucun moment un acces a linux n'est possible si cela n'a pas pas ete
prevus
--
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" a écrit dans le message de news:
helios wrote:
tes utilisateurs postgreSQL peuvent se connecter linux ?
Bien sur que non (sauf si c'est voulu, mais en fait, il y a pas de lien de cause a effet).
exemple si je creer l'utilisateur toto sous PostgreSQL est ce que je peux
faire une connection linux avec toto comme users ?
Bien sur que oui.
met toi d'accord avec le precedent il dit le contraire
si tu cree toto sous pick toto peux se connecter sous linux suivant les droit et avec le password que tu lui a creer sous pick
Ben ca va, comme trou de securite c'est pas trop majeur. Il y a plus qu'a lui donner les droits root aussi a l'utilisateur, comme ca tout le sera content.
mais on peut lui donner les droits root , d'ailleur root est un utilisateur de pick
bien entendu l'utilisateur toto n'existait pas sous linux avant sa creation
dans le sgbd
Mais quelle bouse. Tu peux continuer a nous en parler, ca me subjugue un tel niveau d'insecurite.
justement pick est plus securise qu' une base sql car il geres la securite lui jusqu'a celle du system tandis que avec les base sql il faut se
connecter sous un users system avant d'etre dans le sgbd donc rien n'empeche de sortir ou ne pas rentrer dans le sgbd et de faire un su et vogue le pirate tandis que sous pick on n'a pas le choix l'utilisateur lambda rentre dans pick et ne peux en sortir que deconnecter a aucun moment un acces a linux n'est possible si cela n'a pas pas ete prevus
-- 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
"Stephane TOUGARD" a écrit dans le message de news:
helios wrote:
ensuite openqm contournant les limites du system d'exploitation il faut qu'il est un acces root
Putain, comment j'ai bien fait de pas passer root pour lancer cette merde qui allait rependre toutes ses saloperies partout en contournant les limitation de ma Gentoo.
Et le README livre avec l'archive correspond a l'archive.
desole impossible a savoir le readme ne peut pas se charger
man more
Ca pourrait t'aider a pas passer pour un con.
j'ai dis peux pas se charger pas peut pas ce lire avant de lire un fichier il fauit peut etre l'avoir charger hors le readme a cette adresse ne peurt pas etre charger
-- 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@unices.org> a écrit dans le message de
news:lrmdr2-3kb.ln1@gulliver.unices.org...
helios wrote:
ensuite openqm contournant les limites du system d'exploitation il faut
qu'il est un acces root
Putain, comment j'ai bien fait de pas passer root pour lancer cette
merde qui allait rependre toutes ses saloperies partout en contournant
les limitation de ma Gentoo.
Et le README livre avec l'archive correspond a l'archive.
desole impossible a savoir le readme ne peut pas se charger
man more
Ca pourrait t'aider a pas passer pour un con.
j'ai dis peux pas se charger pas peut pas ce lire avant de lire un fichier
il fauit peut etre l'avoir charger hors le readme a cette adresse ne peurt
pas etre charger
--
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" a écrit dans le message de news:
helios wrote:
ensuite openqm contournant les limites du system d'exploitation il faut qu'il est un acces root
Putain, comment j'ai bien fait de pas passer root pour lancer cette merde qui allait rependre toutes ses saloperies partout en contournant les limitation de ma Gentoo.
Et le README livre avec l'archive correspond a l'archive.
desole impossible a savoir le readme ne peut pas se charger
man more
Ca pourrait t'aider a pas passer pour un con.
j'ai dis peux pas se charger pas peut pas ce lire avant de lire un fichier il fauit peut etre l'avoir charger hors le readme a cette adresse ne peurt pas etre charger
-- 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:
pas la separation la gestion ainsi sauf erreur ton utilisateur applicatif passe par unix pour ce connecter puisque ta sgbd ne sait pas gerer un utilisateur systeme et a donc besoin d'avoir un utilisateur system qu'est ce qui enpeche un "pirate" de sortir ou ne pas rentrer dans le sgbd pour hacker linux ? tandis que sous pick il n'a pas le choix il entre directement dans pick et ne peut sortir que deconnecter. sauf si c'est pick la sgbd et que l'administrateur a decider d'autorise root au connecte
Tu veux pas faire faire un tout petit effort pour ecrire des phrases comprehensibles.
Ou as tu vu que PostgreSQL ou MySQL ou Oracle ont besoin d'un utilisateur systeme pour chaque utilisateur de la base de donnees ? chaque serveur gere lui meme les acces et n'a pas besoin du systeme pour gerer ces acces. Pas plus que la base ne modifie le systeme en quoi que ce soit. Par contre, c'est possible de lier les user de la base avec les user du systeme, mais c'est une option.
il y a yune difference entre l'administration et les donnees tu peux flingue ta base de donne sans corrompre le systeme d'utilisateur et peripherique par contre dans les sgbd ou il faut un utilisateur system avant de se connecter tu peux flinguer tout avant meme d'entrer dans le sgbd , n'importe qui a acces au system d'exploitation c'est vachement securise comme truc il suffit de taper su et vogue le pirate
Mais dis donc coco, tu as deja utilise et configure un Unix et une base de donnee standard type Oracle ou PostgreSQL ? non ? ben tu devrais, parce que la, a part nous etaler ton incompetance totale sur le sujet, tu n'apportes pas grand chose au debat.
Donc on va repeter pour ta gouverne et pour la 10eme fois, il n'y a aucun rapport (sauf si on le configure comme tel) entre les users du SGBD et ceux du systeme.
-- 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:
pas la separation la gestion ainsi sauf erreur ton utilisateur applicatif
passe par unix pour ce connecter puisque ta sgbd ne sait pas gerer un
utilisateur systeme et a donc besoin d'avoir un utilisateur system
qu'est ce qui enpeche un "pirate" de sortir ou ne pas rentrer dans le sgbd
pour hacker linux ? tandis que sous pick il n'a pas le choix il entre
directement dans pick et ne peut sortir que deconnecter.
sauf si c'est pick la sgbd et que l'administrateur a decider d'autorise root
au connecte
Tu veux pas faire faire un tout petit effort pour ecrire des phrases
comprehensibles.
Ou as tu vu que PostgreSQL ou MySQL ou Oracle ont besoin d'un
utilisateur systeme pour chaque utilisateur de la base de donnees ?
chaque serveur gere lui meme les acces et n'a pas besoin du systeme pour
gerer ces acces. Pas plus que la base ne modifie le systeme en quoi que
ce soit. Par contre, c'est possible de lier les user de la base avec les
user du systeme, mais c'est une option.
il y a yune difference entre l'administration et les donnees tu peux
flingue ta base de donne sans corrompre le systeme d'utilisateur et
peripherique par contre dans les sgbd ou il faut un utilisateur system avant
de se connecter tu peux flinguer tout avant meme d'entrer dans le sgbd ,
n'importe qui a acces au system d'exploitation c'est vachement securise
comme truc il suffit de taper su et vogue le pirate
Mais dis donc coco, tu as deja utilise et configure un Unix et une base
de donnee standard type Oracle ou PostgreSQL ? non ? ben tu devrais,
parce que la, a part nous etaler ton incompetance totale sur le sujet,
tu n'apportes pas grand chose au debat.
Donc on va repeter pour ta gouverne et pour la 10eme fois, il n'y a
aucun rapport (sauf si on le configure comme tel) entre les users du
SGBD et ceux du systeme.
--
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
pas la separation la gestion ainsi sauf erreur ton utilisateur applicatif passe par unix pour ce connecter puisque ta sgbd ne sait pas gerer un utilisateur systeme et a donc besoin d'avoir un utilisateur system qu'est ce qui enpeche un "pirate" de sortir ou ne pas rentrer dans le sgbd pour hacker linux ? tandis que sous pick il n'a pas le choix il entre directement dans pick et ne peut sortir que deconnecter. sauf si c'est pick la sgbd et que l'administrateur a decider d'autorise root au connecte
Tu veux pas faire faire un tout petit effort pour ecrire des phrases comprehensibles.
Ou as tu vu que PostgreSQL ou MySQL ou Oracle ont besoin d'un utilisateur systeme pour chaque utilisateur de la base de donnees ? chaque serveur gere lui meme les acces et n'a pas besoin du systeme pour gerer ces acces. Pas plus que la base ne modifie le systeme en quoi que ce soit. Par contre, c'est possible de lier les user de la base avec les user du systeme, mais c'est une option.
il y a yune difference entre l'administration et les donnees tu peux flingue ta base de donne sans corrompre le systeme d'utilisateur et peripherique par contre dans les sgbd ou il faut un utilisateur system avant de se connecter tu peux flinguer tout avant meme d'entrer dans le sgbd , n'importe qui a acces au system d'exploitation c'est vachement securise comme truc il suffit de taper su et vogue le pirate
Mais dis donc coco, tu as deja utilise et configure un Unix et une base de donnee standard type Oracle ou PostgreSQL ? non ? ben tu devrais, parce que la, a part nous etaler ton incompetance totale sur le sujet, tu n'apportes pas grand chose au debat.
Donc on va repeter pour ta gouverne et pour la 10eme fois, il n'y a aucun rapport (sauf si on le configure comme tel) entre les users du SGBD et ceux du systeme.
-- 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
bonjour
le vendredi je ne suis pas tres performant et le matin d'une maniere generale c'est pire
tes liens sont imbitables
si j'ai bien compris et encore j'ai des doutes l'on a des (donnees+des tables index)+ des tables de "dico" et un utilisateur
l'utilisateur tape dans le dico qui pointe -> sur les tables d'index de la base -> qui donne acces aux donnees
c'est ça please
non il y a les fichiers et les dicos le proppre de pick est que tout ce qui ne releves pas de la pure utilisation des donnees est geres par le noyaux (pas d'index au niveau de l'users) pas de merise pas uml juste les donnees et les dicos
pour l'uml tu vas avoir du mal a demontrer qu'il n'y en a pas mais bon passons
ton truc en toute honnete
cela ressemble a un piege a cons ou rectification comment rendre son client captif
ton dico dis moi c'est qui qui le cree et comment il fait ton client si par un malencontreux matin il decide de migrer il fait migrer son dico
ce qui fait que pick est hyper performant par rapport au sql et autre systeme SGBD car tout est hyper optimise et dans le noyaux du sgbd et non en surcouche comme sur sql
je m'en fous et perso pour les applis je rajoute une couche avec jdbc le sql je ne me penche dessus qu'une fois avec bouquin et doc et puis je clique comme un fou sur tout ce qui bouge
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
bonjour
le vendredi je ne suis pas tres performant et le matin d'une
maniere generale c'est pire
tes liens sont imbitables
si j'ai bien compris et encore j'ai des doutes
l'on a des (donnees+des tables index)+ des tables de "dico" et un
utilisateur
l'utilisateur tape dans le dico qui pointe -> sur les tables d'index de
la base -> qui donne acces aux donnees
c'est ça please
non il y a les fichiers et les dicos le proppre de pick est que tout ce qui
ne releves pas de la pure utilisation des donnees est geres par le noyaux
(pas d'index au niveau de l'users) pas de merise pas uml
juste les donnees et les dicos
pour l'uml tu vas avoir du mal a demontrer qu'il n'y en a pas
mais bon passons
ton truc en toute honnete
cela ressemble a un piege a cons ou rectification
comment rendre son client captif
ton dico dis moi c'est qui qui le cree et comment il fait ton client
si par un malencontreux matin il decide de migrer
il fait migrer son dico
ce qui fait que pick est hyper performant par rapport au sql et autre
systeme SGBD car tout est hyper optimise et dans le noyaux du sgbd et non en
surcouche comme sur sql
je m'en fous et perso pour les applis je rajoute une couche avec jdbc
le sql je ne me penche dessus qu'une fois avec bouquin et doc
et puis je clique comme un fou sur tout ce qui bouge
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
le vendredi je ne suis pas tres performant et le matin d'une maniere generale c'est pire
tes liens sont imbitables
si j'ai bien compris et encore j'ai des doutes l'on a des (donnees+des tables index)+ des tables de "dico" et un utilisateur
l'utilisateur tape dans le dico qui pointe -> sur les tables d'index de la base -> qui donne acces aux donnees
c'est ça please
non il y a les fichiers et les dicos le proppre de pick est que tout ce qui ne releves pas de la pure utilisation des donnees est geres par le noyaux (pas d'index au niveau de l'users) pas de merise pas uml juste les donnees et les dicos
pour l'uml tu vas avoir du mal a demontrer qu'il n'y en a pas mais bon passons
ton truc en toute honnete
cela ressemble a un piege a cons ou rectification comment rendre son client captif
ton dico dis moi c'est qui qui le cree et comment il fait ton client si par un malencontreux matin il decide de migrer il fait migrer son dico
ce qui fait que pick est hyper performant par rapport au sql et autre systeme SGBD car tout est hyper optimise et dans le noyaux du sgbd et non en surcouche comme sur sql
je m'en fous et perso pour les applis je rajoute une couche avec jdbc le sql je ne me penche dessus qu'une fois avec bouquin et doc et puis je clique comme un fou sur tout ce qui bouge
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
