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
"X.B" a écrit dans le message de news:42e66d7f$0$6692$
helios wrote:
Le tout sans le moindre acces au systeme, puisque ca n'a aucun rapport.
faux ton sgbd a acces au system donc il suffit de basculer en shell ou d'arreter le sgbd pour etre sur le system
en matiere de securite pour une banque il vaut mieux quoi que le gardien est seulement la cle de la porte d'entre et que le coffre soit ouvert ou que la meme cle ouvre la porte et la salle des coffre coffre mais que le coffre soit ferme ? il est preferable que le gardien n'est pas acces a la salle des coffre
(quand à avoir la clef !) ... en plus cela rend son agression inutile ...
un serveur totalement securise est un serveur off
"X.B" <moi@meme.fr> a écrit dans le message de
news:42e66d7f$0$6692$626a14ce@news.free.fr...
helios wrote:
Le tout sans le moindre acces au systeme, puisque ca n'a aucun rapport.
faux ton sgbd a acces au system donc il suffit de basculer en shell ou
d'arreter le sgbd pour etre sur le system
en matiere de securite pour une banque il vaut mieux quoi
que le gardien est seulement la cle de la porte d'entre et que le coffre
soit ouvert
ou que la meme cle ouvre la porte et la salle des coffre coffre mais que
le coffre soit ferme ?
il est preferable que le gardien n'est pas acces a la salle des coffre
(quand à avoir la clef !) ... en plus cela rend son agression inutile ...
"X.B" a écrit dans le message de news:42e66d7f$0$6692$
helios wrote:
Le tout sans le moindre acces au systeme, puisque ca n'a aucun rapport.
faux ton sgbd a acces au system donc il suffit de basculer en shell ou d'arreter le sgbd pour etre sur le system
en matiere de securite pour une banque il vaut mieux quoi que le gardien est seulement la cle de la porte d'entre et que le coffre soit ouvert ou que la meme cle ouvre la porte et la salle des coffre coffre mais que le coffre soit ferme ? il est preferable que le gardien n'est pas acces a la salle des coffre
(quand à avoir la clef !) ... en plus cela rend son agression inutile ...
un serveur totalement securise est un serveur off
Yannick Patois
Bonjour,
Je vais essayer d'expliquer ce que j'ai crus comprendre du fonctionnement de pick (auquel je ne connais rien) à travers ce qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre vous, d'où des critiques que je juge un peu rapides et infondées.
Le fonctionnement me parait être le suivant:
Un démon (appelons le pickd-login) tournant sous root attend les connections. Ce démon ne sait faire que "login: password:", une fois la personne identifiée, il fork un process user (appelons le pick-user) dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement simple: validation du password et fork sous l'uid validé: on peut raisonnablement penser que ce démon peut être très sûr, et qu'un exploit sur le login est très peu probable.
- Une fois loggé, le user pick se trouve bel est bien dans un process user, processus qui ne possède pas de droits particuliers: les fichiers qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les bonnes permissions (indépendemment de restrictions sans doute plus élevées au sein de pick lui-même).
Que ce soit par un exploit interne à la base (escalade de privilège au sein de la base) ou d'un exploit permettant de forker un shell, le user ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une faille sur le système lui-même).
Par comparaison, une base de donnée mysql (par exemple) tourne sous un user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un exploit interne comme un exploit donnant un shell, permet potentiellement à un utilisateur de la base de lire et écrire sur l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes les bases.
Si j'ai bien compris le principe, pick me parait effectivement plus sécurisé sur ce plan.
Bien sur, il faut bien quelque part des utilisateurs privilégiés, tournant sous des comptes privilégiés, il est même probable que l'admin de la base doive tourner en root, ou du moins avec un paquet de suids: ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.
Le plus gros reproche que je vois à ce truc (si j'ai bien compris comment ca marchait), c'est que c'est très peu portable et très dépendant du système: par exemple, de nombreux unix ont un UID sur 15 bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on voudrait plus de 32000 utilisateurs distincts? De la même façon, utiliser les droits unix pour discriminer des accès partagés me semble délicat sans ACL; hors de nombreux FS unix ne disposent pas d'ACL. On fait comment ?
Bon, j'ai peut-être mal compris, mais logiquement, je ne vois que ca de possible au vue des messages d'helios.
Yannick
PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet comparable à poster sur fsp: la pénible impression qu'ici toute discussion rationnelle, respectueuse de l'autre et honnête est impossible, et que tous les intervenants ne peuvent ressortir que salit d'un tel échange... Je n'avais pas cette impression autrefois.
Bonjour,
Je vais essayer d'expliquer ce que j'ai crus comprendre du
fonctionnement de pick (auquel je ne connais rien) à travers ce
qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre
vous, d'où des critiques que je juge un peu rapides et infondées.
Le fonctionnement me parait être le suivant:
Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.
- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).
Que ce soit par un exploit interne à la base (escalade de privilège au
sein de la base) ou d'un exploit permettant de forker un shell, le user
ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une
faille sur le système lui-même).
Par comparaison, une base de donnée mysql (par exemple) tourne sous un
user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les
bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un
exploit interne comme un exploit donnant un shell, permet
potentiellement à un utilisateur de la base de lire et écrire sur
l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes
les bases.
Si j'ai bien compris le principe, pick me parait effectivement plus
sécurisé sur ce plan.
Bien sur, il faut bien quelque part des utilisateurs privilégiés,
tournant sous des comptes privilégiés, il est même probable que l'admin
de la base doive tourner en root, ou du moins avec un paquet de suids:
ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.
Le plus gros reproche que je vois à ce truc (si j'ai bien compris
comment ca marchait), c'est que c'est très peu portable et très
dépendant du système: par exemple, de nombreux unix ont un UID sur 15
bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on
voudrait plus de 32000 utilisateurs distincts?
De la même façon, utiliser les droits unix pour discriminer des accès
partagés me semble délicat sans ACL; hors de nombreux FS unix ne
disposent pas d'ACL. On fait comment ?
Bon, j'ai peut-être mal compris, mais logiquement, je ne vois que ca de
possible au vue des messages d'helios.
Yannick
PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet
comparable à poster sur fsp: la pénible impression qu'ici toute
discussion rationnelle, respectueuse de l'autre et honnête est
impossible, et que tous les intervenants ne peuvent ressortir que salit
d'un tel échange...
Je n'avais pas cette impression autrefois.
Je vais essayer d'expliquer ce que j'ai crus comprendre du fonctionnement de pick (auquel je ne connais rien) à travers ce qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre vous, d'où des critiques que je juge un peu rapides et infondées.
Le fonctionnement me parait être le suivant:
Un démon (appelons le pickd-login) tournant sous root attend les connections. Ce démon ne sait faire que "login: password:", une fois la personne identifiée, il fork un process user (appelons le pick-user) dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement simple: validation du password et fork sous l'uid validé: on peut raisonnablement penser que ce démon peut être très sûr, et qu'un exploit sur le login est très peu probable.
- Une fois loggé, le user pick se trouve bel est bien dans un process user, processus qui ne possède pas de droits particuliers: les fichiers qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les bonnes permissions (indépendemment de restrictions sans doute plus élevées au sein de pick lui-même).
Que ce soit par un exploit interne à la base (escalade de privilège au sein de la base) ou d'un exploit permettant de forker un shell, le user ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une faille sur le système lui-même).
Par comparaison, une base de donnée mysql (par exemple) tourne sous un user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un exploit interne comme un exploit donnant un shell, permet potentiellement à un utilisateur de la base de lire et écrire sur l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes les bases.
Si j'ai bien compris le principe, pick me parait effectivement plus sécurisé sur ce plan.
Bien sur, il faut bien quelque part des utilisateurs privilégiés, tournant sous des comptes privilégiés, il est même probable que l'admin de la base doive tourner en root, ou du moins avec un paquet de suids: ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.
Le plus gros reproche que je vois à ce truc (si j'ai bien compris comment ca marchait), c'est que c'est très peu portable et très dépendant du système: par exemple, de nombreux unix ont un UID sur 15 bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on voudrait plus de 32000 utilisateurs distincts? De la même façon, utiliser les droits unix pour discriminer des accès partagés me semble délicat sans ACL; hors de nombreux FS unix ne disposent pas d'ACL. On fait comment ?
Bon, j'ai peut-être mal compris, mais logiquement, je ne vois que ca de possible au vue des messages d'helios.
Yannick
PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet comparable à poster sur fsp: la pénible impression qu'ici toute discussion rationnelle, respectueuse de l'autre et honnête est impossible, et que tous les intervenants ne peuvent ressortir que salit d'un tel échange... Je n'avais pas cette impression autrefois.
helios
"JustMe" a écrit dans le message de news:
Stanislas de Kertanguy a pensé très fort :
helios wrote:
l'alcool peut creer de l'antropie la debilite aussi quel est votre cas ? les
deux ?
Entropie avec un E, bordel! et ne parlez pas d'entropie sans savoir réellement ce que c'est!
Il doit confondre avec "etable"
quand on a un system pour boeuf (c'est pas moi qui est parler du regard
bovin d'une utilisatrice SQL) l'etable est normale
"JustMe" <pasdespam@merci.beaucoup> a écrit dans le message de
news:mn.d3ec7d57610c9090.15643@merci.beaucoup...
Stanislas de Kertanguy a pensé très fort :
helios <helios@com02.com> wrote:
l'alcool peut creer de l'antropie la debilite aussi quel est votre cas
? les
deux ?
Entropie avec un E, bordel! et ne parlez pas d'entropie sans savoir
réellement ce que c'est!
Il doit confondre avec "etable"
quand on a un system pour boeuf (c'est pas moi qui est parler du regard
bovin d'une utilisatrice SQL) l'etable est normale
l'alcool peut creer de l'antropie la debilite aussi quel est votre cas ? les
deux ?
Entropie avec un E, bordel! et ne parlez pas d'entropie sans savoir réellement ce que c'est!
Il doit confondre avec "etable"
quand on a un system pour boeuf (c'est pas moi qui est parler du regard
bovin d'une utilisatrice SQL) l'etable est normale
helios
"Yannick Patois" a écrit dans le message de news:dc69l2$2fph$
Bonjour,
Je vais essayer d'expliquer ce que j'ai crus comprendre du fonctionnement de pick (auquel je ne connais rien) à travers ce qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre vous, d'où des critiques que je juge un peu rapides et infondées.
Le fonctionnement me parait être le suivant:
Un démon (appelons le pickd-login) tournant sous root attend les connections. Ce démon ne sait faire que "login: password:", une fois la personne identifiée, il fork un process user (appelons le pick-user) dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement simple: validation du password et fork sous l'uid validé: on peut raisonnablement penser que ce démon peut être très sûr, et qu'un exploit sur le login est très peu probable.
- Une fois loggé, le user pick se trouve bel est bien dans un process user, processus qui ne possède pas de droits particuliers: les fichiers qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les bonnes permissions (indépendemment de restrictions sans doute plus élevées au sein de pick lui-même).
Que ce soit par un exploit interne à la base (escalade de privilège au sein de la base) ou d'un exploit permettant de forker un shell, le user ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une faille sur le système lui-même).
Par comparaison, une base de donnée mysql (par exemple) tourne sous un user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un exploit interne comme un exploit donnant un shell, permet potentiellement à un utilisateur de la base de lire et écrire sur l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes les bases.
Si j'ai bien compris le principe, pick me parait effectivement plus sécurisé sur ce plan.
c'est ce que je me tue a leur expliquer mais il y a pas plus sourd que celui qui ne veux pas entendre
Bien sur, il faut bien quelque part des utilisateurs privilégiés, tournant sous des comptes privilégiés, il est même probable que l'admin de la base doive tourner en root, ou du moins avec un paquet de suids: ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.
les seuls qui ont un acces root sont l'administrateur et ceux qui ont ete choisi comme ayant cet acces
Le plus gros reproche que je vois à ce truc (si j'ai bien compris comment ca marchait), c'est que c'est très peu portable et très dépendant du système: par exemple, de nombreux unix ont un UID sur 15 bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on voudrait plus de 32000 utilisateurs distincts? De la même façon, utiliser les droits unix pour discriminer des accès partagés me semble délicat sans ACL; hors de nombreux FS unix ne disposent pas d'ACL. On fait comment ?
PICK est le system le plus portable chaque system a sa couche administration propre dependant du matos et system d'exploit mais apres tout le reste est identique c'est un standart ainsi une meme base peut migres d'un IBM43 a un PC sous linux ou windows sans retouche un simple transfert des fichiers en kermit suffit
PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet comparable à poster sur fsp: la pénible impression qu'ici toute discussion rationnelle, respectueuse de l'autre et honnête est impossible, et que tous les intervenants ne peuvent ressortir que salit d'un tel échange... Je n'avais pas cette impression autrefois.
la peur du chomage excuse bien des choses car les systemes pick sont oriente
utilisateur et sont plus puissant que les SGBDR , les develloppeurs de SGBDR obtient des resultat moins bon que les utilisateur PICK
"Yannick Patois" <patois@calvix.org> a écrit dans le message de
news:dc69l2$2fph$1@biggoron.nerim.net...
Bonjour,
Je vais essayer d'expliquer ce que j'ai crus comprendre du
fonctionnement de pick (auquel je ne connais rien) à travers ce
qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre
vous, d'où des critiques que je juge un peu rapides et infondées.
Le fonctionnement me parait être le suivant:
Un démon (appelons le pickd-login) tournant sous root attend les
connections. Ce démon ne sait faire que "login: password:", une fois la
personne identifiée, il fork un process user (appelons le pick-user)
dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement
simple: validation du password et fork sous l'uid validé: on peut
raisonnablement penser que ce démon peut être très sûr, et qu'un exploit
sur le login est très peu probable.
- Une fois loggé, le user pick se trouve bel est bien dans un process
user, processus qui ne possède pas de droits particuliers: les fichiers
qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les
bonnes permissions (indépendemment de restrictions sans doute plus
élevées au sein de pick lui-même).
Que ce soit par un exploit interne à la base (escalade de privilège au
sein de la base) ou d'un exploit permettant de forker un shell, le user
ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une
faille sur le système lui-même).
Par comparaison, une base de donnée mysql (par exemple) tourne sous un
user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les
bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un
exploit interne comme un exploit donnant un shell, permet
potentiellement à un utilisateur de la base de lire et écrire sur
l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes
les bases.
Si j'ai bien compris le principe, pick me parait effectivement plus
sécurisé sur ce plan.
c'est ce que je me tue a leur expliquer mais il y a pas plus sourd que celui
qui ne veux pas entendre
Bien sur, il faut bien quelque part des utilisateurs privilégiés,
tournant sous des comptes privilégiés, il est même probable que l'admin
de la base doive tourner en root, ou du moins avec un paquet de suids:
ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.
les seuls qui ont un acces root sont l'administrateur et ceux qui ont ete
choisi comme ayant cet acces
Le plus gros reproche que je vois à ce truc (si j'ai bien compris
comment ca marchait), c'est que c'est très peu portable et très
dépendant du système: par exemple, de nombreux unix ont un UID sur 15
bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on
voudrait plus de 32000 utilisateurs distincts?
De la même façon, utiliser les droits unix pour discriminer des accès
partagés me semble délicat sans ACL; hors de nombreux FS unix ne
disposent pas d'ACL. On fait comment ?
PICK est le system le plus portable chaque system a sa couche administration
propre dependant du matos et system d'exploit mais apres tout le reste est
identique c'est un standart
ainsi une meme base peut migres d'un IBM43 a un PC sous linux ou windows
sans retouche un simple transfert des fichiers en kermit suffit
PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet
comparable à poster sur fsp: la pénible impression qu'ici toute
discussion rationnelle, respectueuse de l'autre et honnête est
impossible, et que tous les intervenants ne peuvent ressortir que salit
d'un tel échange...
Je n'avais pas cette impression autrefois.
la peur du chomage excuse bien des choses car les systemes pick sont oriente
utilisateur et sont plus puissant que les SGBDR , les develloppeurs de SGBDR
obtient des resultat moins bon que les utilisateur PICK
"Yannick Patois" a écrit dans le message de news:dc69l2$2fph$
Bonjour,
Je vais essayer d'expliquer ce que j'ai crus comprendre du fonctionnement de pick (auquel je ne connais rien) à travers ce qu'hélios en a dit, qui me semble t'il a échappé à beaucoup d'entre vous, d'où des critiques que je juge un peu rapides et infondées.
Le fonctionnement me parait être le suivant:
Un démon (appelons le pickd-login) tournant sous root attend les connections. Ce démon ne sait faire que "login: password:", une fois la personne identifiée, il fork un process user (appelons le pick-user) dans lequel tournera l'interpréteur pick.
- Certes, pickd-login tourne en root, mais son rôle est excessivement simple: validation du password et fork sous l'uid validé: on peut raisonnablement penser que ce démon peut être très sûr, et qu'un exploit sur le login est très peu probable.
- Une fois loggé, le user pick se trouve bel est bien dans un process user, processus qui ne possède pas de droits particuliers: les fichiers qu'il peut lire et modifier sont donc *seulement* les fichiers ayant les bonnes permissions (indépendemment de restrictions sans doute plus élevées au sein de pick lui-même).
Que ce soit par un exploit interne à la base (escalade de privilège au sein de la base) ou d'un exploit permettant de forker un shell, le user ne pourra que s'attaquer à ses propres fichiers (à moins de trouver une faille sur le système lui-même).
Par comparaison, une base de donnée mysql (par exemple) tourne sous un user 'mysql', certes non privilégié, mais ayant accès à *toute* la/les bases que gère ce serveur (le démon doit bien pouvoir y écrire): Un exploit interne comme un exploit donnant un shell, permet potentiellement à un utilisateur de la base de lire et écrire sur l'ensemble des fichiers que le démon peut accéder: c'est à dire toutes les bases.
Si j'ai bien compris le principe, pick me parait effectivement plus sécurisé sur ce plan.
c'est ce que je me tue a leur expliquer mais il y a pas plus sourd que celui qui ne veux pas entendre
Bien sur, il faut bien quelque part des utilisateurs privilégiés, tournant sous des comptes privilégiés, il est même probable que l'admin de la base doive tourner en root, ou du moins avec un paquet de suids: ajouter des comptes unix, etc. Mais pas les utilisateurs de bases.
les seuls qui ont un acces root sont l'administrateur et ceux qui ont ete choisi comme ayant cet acces
Le plus gros reproche que je vois à ce truc (si j'ai bien compris comment ca marchait), c'est que c'est très peu portable et très dépendant du système: par exemple, de nombreux unix ont un UID sur 15 bits, avec 32000 comptes maximums: n'existe t'il pas des bases ou l'on voudrait plus de 32000 utilisateurs distincts? De la même façon, utiliser les droits unix pour discriminer des accès partagés me semble délicat sans ACL; hors de nombreux FS unix ne disposent pas d'ACL. On fait comment ?
PICK est le system le plus portable chaque system a sa couche administration propre dependant du matos et system d'exploit mais apres tout le reste est identique c'est un standart ainsi une meme base peut migres d'un IBM43 a un PC sous linux ou windows sans retouche un simple transfert des fichiers en kermit suffit
PS: J'ai longuement hésité avant de poster ici... Ca me fais un effet comparable à poster sur fsp: la pénible impression qu'ici toute discussion rationnelle, respectueuse de l'autre et honnête est impossible, et que tous les intervenants ne peuvent ressortir que salit d'un tel échange... Je n'avais pas cette impression autrefois.
la peur du chomage excuse bien des choses car les systemes pick sont oriente
utilisateur et sont plus puissant que les SGBDR , les develloppeurs de SGBDR obtient des resultat moins bon que les utilisateur PICK
helios
"Stephane Zuckerman" a écrit dans le message de news:
Si on lui demande un truc pas prévu par l'appli, elle prend son plus beau
regard bovin et elle dit qu'elle peut pas. --
ok je comprends SQL c'est pour les boeufs
Non (et merci de sortir ma phrase hors de son contexte, comme ça tout le monde comprend de quoi on parlait...).
Simplement, la secrétaire n'est pas là pour faire de l'informatique.
la secretaire est la pour faire des stats et l'outil SQL ne lui permet pas
de faire des stat non prevu par les informaticiens donc .... alors qu'avec pick elle fait les stat qu'elle veux sans passer pour un bovidé
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0507261119200.197702@vega.utc.fr...
Si on lui demande un truc pas prévu par l'appli, elle prend son plus
beau
regard bovin et elle dit qu'elle peut pas.
--
ok je comprends SQL c'est pour les boeufs
Non (et merci de sortir ma phrase hors de son contexte, comme ça tout le
monde comprend de quoi on parlait...).
Simplement, la secrétaire n'est pas là pour faire de l'informatique.
la secretaire est la pour faire des stats et l'outil SQL ne lui permet pas
de faire des stat non prevu par les informaticiens donc ....
alors qu'avec pick elle fait les stat qu'elle veux sans passer pour un
bovidé
"Stephane Zuckerman" a écrit dans le message de news:
Si on lui demande un truc pas prévu par l'appli, elle prend son plus beau
regard bovin et elle dit qu'elle peut pas. --
ok je comprends SQL c'est pour les boeufs
Non (et merci de sortir ma phrase hors de son contexte, comme ça tout le monde comprend de quoi on parlait...).
Simplement, la secrétaire n'est pas là pour faire de l'informatique.
la secretaire est la pour faire des stats et l'outil SQL ne lui permet pas
de faire des stat non prevu par les informaticiens donc .... alors qu'avec pick elle fait les stat qu'elle veux sans passer pour un bovidé
Jerome Lambert
"Jerome Lambert" a écrit dans le message de news:
helios wrote:
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui contient malgres le MV 500 champs sans le MV cela en ferais combien de
champ
?la migration vers oracle a ete un bide
Ton expertise FranceTelecom est détaillée ici par exemple? http://fr.scguild.com/usr/3957I.html http://fr.scguild.com/usr/3957R.html
Oui:
1985-1986 Concepteur sous PICK des programmes pour la gestion des Ordres de Construction des NouveauxAbonnés de FRANCE TELECOM et Administration de la machine IN532 (création des comptes, sauvegardes, restauration, arrêt et mise en services de la machine, gestion des incidents), installation des nouveaux postes de travail et imprimantes , liaison avec des micro ordinateurs
C'était il y a 20 ans...
il parait que j'ai travailler depuis 20ans regarde le reste du cv du style du pick universe en 2005
Effectivement, mais le reste du CV me fait furieusement penser à du maintient de l'existant en attendant que le matériel en place meurt de sa belle mort, comme l'étaient les programmeurs COBOL il n'y a pas si longtemps. Quelles que soient les qualités réelles ou supposées des bases MV, le marché a choisi: c'est du SGBD relationnel, interrogeable via le langage SQL, et interfaçable avec du Perl, PHP, Jave, bref tout ce qu'il faut pour faire un joli front-end "mode web"...
"Jerome Lambert" <jerome.lambert@swing.be> a écrit dans le message de
news:3kmd9jFv7suoU2@individual.net...
helios <helios@com02.com> wrote:
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui
contient malgres le MV 500 champs sans le MV cela en ferais combien de
champ
?la migration vers oracle a ete un bide
Ton expertise FranceTelecom est détaillée ici par exemple?
http://fr.scguild.com/usr/3957I.html
http://fr.scguild.com/usr/3957R.html
Oui:
1985-1986 Concepteur sous PICK des programmes pour la gestion des Ordres
de Construction des NouveauxAbonnés de FRANCE TELECOM et Administration
de la machine IN532 (création des comptes, sauvegardes, restauration,
arrêt et mise en services de la machine, gestion des incidents),
installation des nouveaux postes de travail et imprimantes , liaison
avec des micro ordinateurs
C'était il y a 20 ans...
il parait que j'ai travailler depuis 20ans regarde le reste du cv du style
du pick universe en 2005
Effectivement, mais le reste du CV me fait furieusement penser à du
maintient de l'existant en attendant que le matériel en place meurt de
sa belle mort, comme l'étaient les programmeurs COBOL il n'y a pas si
longtemps. Quelles que soient les qualités réelles ou supposées des
bases MV, le marché a choisi: c'est du SGBD relationnel, interrogeable
via le langage SQL, et interfaçable avec du Perl, PHP, Jave, bref tout
ce qu'il faut pour faire un joli front-end "mode web"...
c'est vrai FT a une petite base de 60000000 de ligne telephonique qui contient malgres le MV 500 champs sans le MV cela en ferais combien de
champ
?la migration vers oracle a ete un bide
Ton expertise FranceTelecom est détaillée ici par exemple? http://fr.scguild.com/usr/3957I.html http://fr.scguild.com/usr/3957R.html
Oui:
1985-1986 Concepteur sous PICK des programmes pour la gestion des Ordres de Construction des NouveauxAbonnés de FRANCE TELECOM et Administration de la machine IN532 (création des comptes, sauvegardes, restauration, arrêt et mise en services de la machine, gestion des incidents), installation des nouveaux postes de travail et imprimantes , liaison avec des micro ordinateurs
C'était il y a 20 ans...
il parait que j'ai travailler depuis 20ans regarde le reste du cv du style du pick universe en 2005
Effectivement, mais le reste du CV me fait furieusement penser à du maintient de l'existant en attendant que le matériel en place meurt de sa belle mort, comme l'étaient les programmeurs COBOL il n'y a pas si longtemps. Quelles que soient les qualités réelles ou supposées des bases MV, le marché a choisi: c'est du SGBD relationnel, interrogeable via le langage SQL, et interfaçable avec du Perl, PHP, Jave, bref tout ce qu'il faut pour faire un joli front-end "mode web"...
Jérémy JUST
On Mon, 25 Jul 2005 17:13:49 +0200 Jerome Lambert wrote:
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
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.
C'est peut-être ce que tu voulais dire ici.
Une base de données relationnelle est censée ne pas contenir d'informations redondantes.
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.
C'est peut-être ce que tu voulais dire ici.
Une base de données relationnelle est censée ne pas contenir
d'informations redondantes.
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.
C'est peut-être ce que tu voulais dire ici.
Une base de données relationnelle est censée ne pas contenir d'informations redondantes.
-- Jérémy JUST
Jérémy JUST
On Tue, 26 Jul 2005 11:12:08 +0200 Jerome Lambert wrote:
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV de niveau 128?
C'est impossible à dire sans cas concret, cela m'étonnerait grandement que l'on se retrouve avec des données nécessitant autant de tables (mais je ne suis pas un spécialiste en la matière)
On voit couramment des bases à 60-80 tables, quand on travaille sur des données réelles. Il doit être assez facile de trouver plus compliqué, par exemple quand deux bases ont été fusionnées après leurs conceptions indépendantes.
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables
pour un MV de niveau 128?
C'est impossible à dire sans cas concret, cela m'étonnerait grandement
que l'on se retrouve avec des données nécessitant autant de tables
(mais je ne suis pas un spécialiste en la matière)
On voit couramment des bases à 60-80 tables, quand on travaille
sur des données réelles. Il doit être assez facile de trouver
plus compliqué, par exemple quand deux bases ont été fusionnées après
leurs conceptions indépendantes.
On Tue, 26 Jul 2005 11:12:08 +0200 Jerome Lambert wrote:
la tu as deux table pour un MV de niveau 2 tu envisage 128 tables pour un MV de niveau 128?
C'est impossible à dire sans cas concret, cela m'étonnerait grandement que l'on se retrouve avec des données nécessitant autant de tables (mais je ne suis pas un spécialiste en la matière)
On voit couramment des bases à 60-80 tables, quand on travaille sur des données réelles. Il doit être assez facile de trouver plus compliqué, par exemple quand deux bases ont été fusionnées après leurs conceptions indépendantes.
-- Jérémy JUST
Jérémy JUST
On Wed, 27 Jul 2005 00:44:01 +0200 Jérémy JUST wrote:
On aurait plutôt deux tables:
Ça avait déjà été dit. La prochaine fois, je lirai tout le thread avant de poster...
-- Jérémy JUST
On Wed, 27 Jul 2005 00:44:01 +0200
Jérémy JUST <jeremy_just@netcourrier.com> wrote:
On aurait plutôt deux tables:
Ça avait déjà été dit.
La prochaine fois, je lirai tout le thread avant de poster...
On Wed, 27 Jul 2005 00:44:01 +0200 Jérémy JUST wrote:
On aurait plutôt deux tables:
Ça avait déjà été dit. La prochaine fois, je lirai tout le thread avant de poster...
-- Jérémy JUST
Manuel Leclerc
[...) d'où des critiques que je juge un peu rapides et infondées.
(...] la pénible impression qu'ici toute discussion rationnelle, respectueuse de l'autre et honnête est impossible, et que tous les intervenants ne peuvent ressortir que salit d'un tel échange...
Je suis d'accord avec Yannick.
[...) d'où des critiques que je juge un peu rapides
et infondées.
(...] la pénible impression qu'ici toute discussion
rationnelle, respectueuse de l'autre et honnête est
impossible, et que tous les intervenants ne peuvent
ressortir que salit d'un tel échange...
[...) d'où des critiques que je juge un peu rapides et infondées.
(...] la pénible impression qu'ici toute discussion rationnelle, respectueuse de l'autre et honnête est impossible, et que tous les intervenants ne peuvent ressortir que salit d'un tel échange...
