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
"Stéphane CARPENTIER" a écrit dans le message de news:42ebcb66$0$4044$
helios wrote:
tu as reproduit le principe du MV mais maintenant il te manque les outils
pour utilise avec le php tu recreer un outils mais c'est lourd
Non, non, ça se fait tout seul. Deux lignes de code en plus. La première, c'est : $liste_val = explode(",", $row[$i]); foreach($liste_val as $valeur){ //toutes les istructions que je veux }
J'avais écrit qe je faisais un split, mais c'était une connerie.
le probleme est que reproduire un mecanisme dans sa version simple est facile mais le MV a 128 niveau pas 1 seul tu imagine devoir rajouter 250 ligne de code a chaque operation sur le fichier ?
en multivalue une fois ton fichier structurer tu creer les entrees dans le
dico du fichier
nom instruments Styles 001 A 001 A 001 A indique travail sur un attribut 002 1 002 2 002 3 numero attribut 003 004 005 006 007 008 009 010
Je ne comprends rien à ton exemple, ça me parait très lourd.
http://www.openqm.com/downloads/ref.pdf PAGE 5 POUR LES ARTICLES DE DICO
Ca me donne une liste, mais ça ne m'explique absolument pas le principe que
je ne comprends toujours pas.
le principe tu as un fichier INSTRUMENTS de donnee structure en multivaleur et tu as un dictionnaire de mot clef d''interrogation qui geres le fichier
ainsi ton fichier est gere par les mot clefs nom instruments styles ce qui te permet en utilisant le vocabulaire de faire des requetes
EX TRIER INSTRUMENTS PAR STYLES AVEC INSTRUMENTS ="flute"
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
"Stéphane CARPENTIER" <stef.carpentier@gratuit.fr.invalid> a écrit dans le
message de news:42ebcb66$0$4044$636a15ce@news.free.fr...
helios wrote:
tu as reproduit le principe du MV mais maintenant il te manque les
outils
pour utilise avec le php tu recreer un outils mais c'est lourd
Non, non, ça se fait tout seul. Deux lignes de code en plus.
La première, c'est :
$liste_val = explode(",", $row[$i]);
foreach($liste_val as $valeur){
//toutes les istructions que je veux
}
J'avais écrit qe je faisais un split, mais c'était une connerie.
le probleme est que reproduire un mecanisme dans sa version simple est
facile mais le MV a 128 niveau pas 1 seul tu imagine devoir rajouter 250
ligne de code a chaque operation sur le fichier ?
en multivalue une fois ton fichier structurer tu creer les entrees dans
le
dico du fichier
nom instruments Styles
001 A 001 A 001 A
indique travail sur un attribut
002 1 002 2 002 3
numero attribut
003
004
005
006
007
008
009
010
Je ne comprends rien à ton exemple, ça me parait très lourd.
http://www.openqm.com/downloads/ref.pdf PAGE 5 POUR LES ARTICLES DE
DICO
Ca me donne une liste, mais ça ne m'explique absolument pas le principe
que
je ne comprends toujours pas.
le principe tu as un fichier INSTRUMENTS de donnee structure en multivaleur
et tu as un dictionnaire de mot clef d''interrogation qui geres le fichier
ainsi ton fichier est gere par les mot clefs nom instruments styles ce qui
te permet en utilisant le vocabulaire de faire des requetes
EX TRIER INSTRUMENTS PAR STYLES AVEC INSTRUMENTS ="flute"
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
"Stéphane CARPENTIER" a écrit dans le message de news:42ebcb66$0$4044$
helios wrote:
tu as reproduit le principe du MV mais maintenant il te manque les outils
pour utilise avec le php tu recreer un outils mais c'est lourd
Non, non, ça se fait tout seul. Deux lignes de code en plus. La première, c'est : $liste_val = explode(",", $row[$i]); foreach($liste_val as $valeur){ //toutes les istructions que je veux }
J'avais écrit qe je faisais un split, mais c'était une connerie.
le probleme est que reproduire un mecanisme dans sa version simple est facile mais le MV a 128 niveau pas 1 seul tu imagine devoir rajouter 250 ligne de code a chaque operation sur le fichier ?
en multivalue une fois ton fichier structurer tu creer les entrees dans le
dico du fichier
nom instruments Styles 001 A 001 A 001 A indique travail sur un attribut 002 1 002 2 002 3 numero attribut 003 004 005 006 007 008 009 010
Je ne comprends rien à ton exemple, ça me parait très lourd.
http://www.openqm.com/downloads/ref.pdf PAGE 5 POUR LES ARTICLES DE DICO
Ca me donne une liste, mais ça ne m'explique absolument pas le principe que
je ne comprends toujours pas.
le principe tu as un fichier INSTRUMENTS de donnee structure en multivaleur et tu as un dictionnaire de mot clef d''interrogation qui geres le fichier
ainsi ton fichier est gere par les mot clefs nom instruments styles ce qui te permet en utilisant le vocabulaire de faire des requetes
EX TRIER INSTRUMENTS PAR STYLES AVEC INSTRUMENTS ="flute"
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Michel Billaud
remy writes:
est-ce que tu pourrais faire l'effort de mettre de la ponctuation dans tes posts ?
je n'avais meme pas fait attention a ce detail
Pendant qu'on y est, en français les lettres sont accentuées.
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
remy <remy@fctpas.fr> writes:
est-ce que tu pourrais faire l'effort de
mettre de la ponctuation dans tes posts ?
je n'avais meme pas fait attention a ce detail
Pendant qu'on y est, en français les lettres sont accentuées.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
est-ce que tu pourrais faire l'effort de mettre de la ponctuation dans tes posts ?
je n'avais meme pas fait attention a ce detail
Pendant qu'on y est, en français les lettres sont accentuées.
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Michel Billaud
"helios" writes:
Cobol sera a terme remplacer par java car sauf erreur java peut faire tout ce que cobol fait en etat portable
Les deux ont, du point de vue théorique, la puissance d'expression des machines de Turing, et les deux sont normalisés, et les deux sont en principe portables, et en pratique, hum hum pour les deux.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
"helios" <helios@com02.com> writes:
Cobol sera a terme remplacer par java car sauf erreur java peut faire tout
ce que cobol fait en etat portable
Les deux ont, du point de vue théorique, la puissance d'expression des
machines de Turing, et les deux sont normalisés, et les deux sont en
principe portables, et en pratique, hum hum pour les deux.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Cobol sera a terme remplacer par java car sauf erreur java peut faire tout ce que cobol fait en etat portable
Les deux ont, du point de vue théorique, la puissance d'expression des machines de Turing, et les deux sont normalisés, et les deux sont en principe portables, et en pratique, hum hum pour les deux.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Michel Billaud
Stephane TOUGARD writes:
Stéphane CARPENTIER wrote:
L'autre partie, c'est le Back, c'est le stockage des données, c'est l'ensemble des gros calculs sur ces données. Sur cette partie, c'est encore du Cobol. Et il n'est pas du tout envisagé de remplacer le Cobol. C'est un système qui est très fiable. S'il y a le moindre problème après ou pendant un remplacement, des banques pourraient couler. Ce n'est pas du tout envisagé.
C'est sans doute pour la meme raison que pick n'est pas remplace la ou il tourne.
Ca s'appelle "maintenir l'existant" et ca se justifie pour les raisons sus-evoquees.
On trouve aussi des Apple II, des Windows 3.1, et des applis sous CP/M. L'autre jour j'ai même vu un pdp 11 (70 ? chais plus) seul capable de faire tourner un simulateur de vol (un vrai), sauf réécriture complète dudit logiciel, qui prendrait probablement quelques centaines d'homme*année.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Stephane TOUGARD <stephane@unices.org> writes:
Stéphane CARPENTIER wrote:
L'autre partie, c'est le Back, c'est le stockage des données, c'est
l'ensemble des gros calculs sur ces données. Sur cette partie, c'est encore
du Cobol. Et il n'est pas du tout envisagé de remplacer le Cobol. C'est un
système qui est très fiable. S'il y a le moindre problème après ou pendant
un remplacement, des banques pourraient couler. Ce n'est pas du tout
envisagé.
C'est sans doute pour la meme raison que pick n'est pas remplace la ou
il tourne.
Ca s'appelle "maintenir l'existant" et ca se justifie pour les raisons
sus-evoquees.
On trouve aussi des Apple II, des Windows 3.1, et des applis sous CP/M.
L'autre jour j'ai même vu un pdp 11 (70 ? chais plus) seul capable de
faire tourner un simulateur de vol (un vrai), sauf réécriture complète
dudit logiciel, qui prendrait probablement quelques centaines d'homme*année.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
L'autre partie, c'est le Back, c'est le stockage des données, c'est l'ensemble des gros calculs sur ces données. Sur cette partie, c'est encore du Cobol. Et il n'est pas du tout envisagé de remplacer le Cobol. C'est un système qui est très fiable. S'il y a le moindre problème après ou pendant un remplacement, des banques pourraient couler. Ce n'est pas du tout envisagé.
C'est sans doute pour la meme raison que pick n'est pas remplace la ou il tourne.
Ca s'appelle "maintenir l'existant" et ca se justifie pour les raisons sus-evoquees.
On trouve aussi des Apple II, des Windows 3.1, et des applis sous CP/M. L'autre jour j'ai même vu un pdp 11 (70 ? chais plus) seul capable de faire tourner un simulateur de vol (un vrai), sauf réécriture complète dudit logiciel, qui prendrait probablement quelques centaines d'homme*année.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Michel Billaud
"helios" writes:
de toute maniere les gens d'oracle connaisse oracle et FT en plus a la plus grosse base oracle du monde donc on peut pense que chez FT il y a pas defaut de competence oracle
Il y a une seule plus grosse base oracle du monde, donc on peut penser qu'il y a une seule personne qui connait bien oracle chez FT.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
"helios" <helios@com02.com> writes:
de toute maniere les gens d'oracle connaisse oracle et FT en plus a la plus
grosse base oracle du monde donc on peut pense que chez FT il y a pas defaut
de competence oracle
Il y a une seule plus grosse base oracle du monde, donc on peut penser
qu'il y a une seule personne qui connait bien oracle chez FT.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
de toute maniere les gens d'oracle connaisse oracle et FT en plus a la plus grosse base oracle du monde donc on peut pense que chez FT il y a pas defaut de competence oracle
Il y a une seule plus grosse base oracle du monde, donc on peut penser qu'il y a une seule personne qui connait bien oracle chez FT.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Michel Billaud
"helios" writes:
alors FT a la plus grosse base oracle ce qui ferme le clapet
C'est bien mal nous connaitre.
Alors question, qu'est-ce qui justifie que la base de données Oracle de france Telecom soit si grosse, plus grosse, par exemple, que celle des Impots ? Que celle des caisses de retraites ?
Parce que 29 To octets de données, si j'ai bien lu le chiffre, à diviser par, disons 50 millions de lignes telephoniques, ça fait 580000 octets. Qu'est-ce d'ils foutent avec 580Ko d'information par ligne dans la même base de données hein ? Ca ne serait pas une base de données avec des redondances partout pour cause de mauvaise conception, ça ?
Est-ce que par hasard ça ne serait pas plutôt révélateur de la base de données la plus naze ?
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
"helios" <helios@com02.com> writes:
alors FT a la plus grosse base oracle ce qui ferme le clapet
C'est bien mal nous connaitre.
Alors question, qu'est-ce qui justifie que la base de données Oracle
de france Telecom soit si grosse, plus grosse, par exemple, que celle
des Impots ? Que celle des caisses de retraites ?
Parce que 29 To octets de données, si j'ai bien lu le chiffre, à
diviser par, disons 50 millions de lignes telephoniques, ça fait
580000 octets. Qu'est-ce d'ils foutent avec 580Ko d'information par
ligne dans la même base de données hein ? Ca ne serait pas une base
de données avec des redondances partout pour cause de mauvaise
conception, ça ?
Est-ce que par hasard ça ne serait pas plutôt révélateur de la base de
données la plus naze ?
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
alors FT a la plus grosse base oracle ce qui ferme le clapet
C'est bien mal nous connaitre.
Alors question, qu'est-ce qui justifie que la base de données Oracle de france Telecom soit si grosse, plus grosse, par exemple, que celle des Impots ? Que celle des caisses de retraites ?
Parce que 29 To octets de données, si j'ai bien lu le chiffre, à diviser par, disons 50 millions de lignes telephoniques, ça fait 580000 octets. Qu'est-ce d'ils foutent avec 580Ko d'information par ligne dans la même base de données hein ? Ca ne serait pas une base de données avec des redondances partout pour cause de mauvaise conception, ça ?
Est-ce que par hasard ça ne serait pas plutôt révélateur de la base de données la plus naze ?
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Michel Billaud
Stephane Zuckerman writes:
A partir du moment où tu as de l'ethernet, ne me dis pas que ton système ne sait pas gérer autre chose que du kermit. Il gère forcément plus récent et mieux pensé que ce protocole désuet.
Même des trucs modernes et aussi bien conçus que FTP.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Stephane Zuckerman <szuckerm@etu.utc.fr> writes:
A partir du moment où tu as de l'ethernet, ne me dis pas que ton système
ne sait pas gérer autre chose que du kermit. Il gère forcément plus récent
et mieux pensé que ce protocole désuet.
Même des trucs modernes et aussi bien conçus que FTP.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
A partir du moment où tu as de l'ethernet, ne me dis pas que ton système ne sait pas gérer autre chose que du kermit. Il gère forcément plus récent et mieux pensé que ce protocole désuet.
Même des trucs modernes et aussi bien conçus que FTP.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
JustMe
Michel Billaud avait prétendu :
Stephane TOUGARD writes:
Stéphane CARPENTIER wrote:
L'autre partie, c'est le Back, c'est le stockage des données, c'est l'ensemble des gros calculs sur ces données. Sur cette partie, c'est encore du Cobol. Et il n'est pas du tout envisagé de remplacer le Cobol. C'est un système qui est très fiable. S'il y a le moindre problème après ou pendant un remplacement, des banques pourraient couler. Ce n'est pas du tout envisagé.
C'est sans doute pour la meme raison que pick n'est pas remplace la ou il tourne.
Ca s'appelle "maintenir l'existant" et ca se justifie pour les raisons sus-evoquees.
On trouve aussi des Apple II, des Windows 3.1, et des applis sous CP/M. L'autre jour j'ai même vu un pdp 11 (70 ? chais plus) seul capable de faire tourner un simulateur de vol (un vrai), sauf réécriture complète dudit logiciel, qui prendrait probablement quelques centaines d'homme*année.
L'autre partie, c'est le Back, c'est le stockage des données, c'est
l'ensemble des gros calculs sur ces données. Sur cette partie, c'est encore
du Cobol. Et il n'est pas du tout envisagé de remplacer le Cobol. C'est un
système qui est très fiable. S'il y a le moindre problème après ou pendant
un remplacement, des banques pourraient couler. Ce n'est pas du tout
envisagé.
C'est sans doute pour la meme raison que pick n'est pas remplace la ou
il tourne.
Ca s'appelle "maintenir l'existant" et ca se justifie pour les raisons
sus-evoquees.
On trouve aussi des Apple II, des Windows 3.1, et des applis sous CP/M.
L'autre jour j'ai même vu un pdp 11 (70 ? chais plus) seul capable de
faire tourner un simulateur de vol (un vrai), sauf réécriture complète
dudit logiciel, qui prendrait probablement quelques centaines d'homme*année.
L'autre partie, c'est le Back, c'est le stockage des données, c'est l'ensemble des gros calculs sur ces données. Sur cette partie, c'est encore du Cobol. Et il n'est pas du tout envisagé de remplacer le Cobol. C'est un système qui est très fiable. S'il y a le moindre problème après ou pendant un remplacement, des banques pourraient couler. Ce n'est pas du tout envisagé.
C'est sans doute pour la meme raison que pick n'est pas remplace la ou il tourne.
Ca s'appelle "maintenir l'existant" et ca se justifie pour les raisons sus-evoquees.
On trouve aussi des Apple II, des Windows 3.1, et des applis sous CP/M. L'autre jour j'ai même vu un pdp 11 (70 ? chais plus) seul capable de faire tourner un simulateur de vol (un vrai), sauf réécriture complète dudit logiciel, qui prendrait probablement quelques centaines d'homme*année.
Michel Billaud a utilisé son clavier pour écrire :
"helios" writes:
alors FT a la plus grosse base oracle ce qui ferme le clapet
C'est bien mal nous connaitre.
Alors question, qu'est-ce qui justifie que la base de données Oracle de france Telecom soit si grosse, plus grosse, par exemple, que celle des Impots ? Que celle des caisses de retraites ?
Parce que 29 To octets de données, si j'ai bien lu le chiffre, à diviser par, disons 50 millions de lignes telephoniques, ça fait 580000 octets. Qu'est-ce d'ils foutent avec 580Ko d'information par ligne dans la même base de données hein ? Ca ne serait pas une base de données avec des redondances partout pour cause de mauvaise conception, ça ?
Est-ce que par hasard ça ne serait pas plutôt révélateur de la base de données la plus naze ?
MB
Non c'est juste la base pour les requetes judiciaires et la detection de fraude qui garde trace des appels passés/emis/non aboutis a partir d'une ligne fixe ou mobile (et tout un tas d'autres détails utiles aux enquetes) pendant 1 an.
Michel Billaud a utilisé son clavier pour écrire :
"helios" <helios@com02.com> writes:
alors FT a la plus grosse base oracle ce qui ferme le clapet
C'est bien mal nous connaitre.
Alors question, qu'est-ce qui justifie que la base de données Oracle
de france Telecom soit si grosse, plus grosse, par exemple, que celle
des Impots ? Que celle des caisses de retraites ?
Parce que 29 To octets de données, si j'ai bien lu le chiffre, à
diviser par, disons 50 millions de lignes telephoniques, ça fait
580000 octets. Qu'est-ce d'ils foutent avec 580Ko d'information par
ligne dans la même base de données hein ? Ca ne serait pas une base
de données avec des redondances partout pour cause de mauvaise
conception, ça ?
Est-ce que par hasard ça ne serait pas plutôt révélateur de la base de
données la plus naze ?
MB
Non c'est juste la base pour les requetes judiciaires et la detection
de fraude qui garde trace des appels passés/emis/non aboutis a partir
d'une ligne fixe ou mobile (et tout un tas d'autres détails utiles aux
enquetes) pendant 1 an.
Michel Billaud a utilisé son clavier pour écrire :
"helios" writes:
alors FT a la plus grosse base oracle ce qui ferme le clapet
C'est bien mal nous connaitre.
Alors question, qu'est-ce qui justifie que la base de données Oracle de france Telecom soit si grosse, plus grosse, par exemple, que celle des Impots ? Que celle des caisses de retraites ?
Parce que 29 To octets de données, si j'ai bien lu le chiffre, à diviser par, disons 50 millions de lignes telephoniques, ça fait 580000 octets. Qu'est-ce d'ils foutent avec 580Ko d'information par ligne dans la même base de données hein ? Ca ne serait pas une base de données avec des redondances partout pour cause de mauvaise conception, ça ?
Est-ce que par hasard ça ne serait pas plutôt révélateur de la base de données la plus naze ?
MB
Non c'est juste la base pour les requetes judiciaires et la detection de fraude qui garde trace des appels passés/emis/non aboutis a partir d'une ligne fixe ou mobile (et tout un tas d'autres détails utiles aux enquetes) pendant 1 an.
Michel Billaud
"helios" writes:
les binaires sous pick sont executable dans tout les pick donc independament
des plateformes et OS
Voyez-vous ça... Alors ce sont des scripts qui utilisent les fonctions du SGBD. Comme SQL, quoi...
j'ai parler d'exucutable pas de script il y a une diference entre un fichier script et un fichier compile
En fait, pas tant que ça. Compiler, c'est juste traduire un langage d'une machine pour une autre machine. On peut très bien imaginer (et je suis sur qu'en cherchant...) que la compilation d'un source produise du Lisp, par exemple. Lequel peut être interprété ou compilé, et peut aussi être considéré comme un script.
Il est bien possible que le fameux "binaire portable" pick soit en fait un bytecode, comme de vulgaires .class java (ou les fichiers bytecode produits par beaucoup de compilateurs Cobol).
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
"helios" <helios@com02.com> writes:
les binaires sous pick sont executable dans tout les pick donc
independament
des plateformes et OS
Voyez-vous ça... Alors ce sont des scripts qui utilisent les fonctions du
SGBD. Comme SQL, quoi...
j'ai parler d'exucutable pas de script il y a une diference entre un fichier
script et un fichier compile
En fait, pas tant que ça. Compiler, c'est juste traduire un langage
d'une machine pour une autre machine. On peut très bien imaginer (et
je suis sur qu'en cherchant...) que la compilation d'un source
produise du Lisp, par exemple. Lequel peut être interprété ou compilé,
et peut aussi être considéré comme un script.
Il est bien possible que le fameux "binaire portable" pick soit en
fait un bytecode, comme de vulgaires .class java (ou les fichiers
bytecode produits par beaucoup de compilateurs Cobol).
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
les binaires sous pick sont executable dans tout les pick donc independament
des plateformes et OS
Voyez-vous ça... Alors ce sont des scripts qui utilisent les fonctions du SGBD. Comme SQL, quoi...
j'ai parler d'exucutable pas de script il y a une diference entre un fichier script et un fichier compile
En fait, pas tant que ça. Compiler, c'est juste traduire un langage d'une machine pour une autre machine. On peut très bien imaginer (et je suis sur qu'en cherchant...) que la compilation d'un source produise du Lisp, par exemple. Lequel peut être interprété ou compilé, et peut aussi être considéré comme un script.
Il est bien possible que le fameux "binaire portable" pick soit en fait un bytecode, comme de vulgaires .class java (ou les fichiers bytecode produits par beaucoup de compilateurs Cobol).
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
