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
Un beau de jour, ou pour etre plus precis le 04/08/2005, Franck Yvonnet a déclamé dans le message le texte d'une qualité littéraire indéniable suivant :
Ainsi Parlait Michel Billaud
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de données ?
Justement, la base de donnée d'abonnés résidentiels n'es pas centralisée mais réparti selon un découpage régionnal spécifique à FT.
on ^parlait pas de cette base la, on parlait de "symphonie"
Un beau de jour, ou pour etre plus precis le 04/08/2005, Franck Yvonnet
a déclamé dans le message <slrndf39u8.pp1.fyvonnet@gwyneth.glou.net> le
texte d'une qualité littéraire indéniable suivant :
Ainsi Parlait Michel Billaud <billaud@labri.u-bordeaux.fr>
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base
de données ?
Justement, la base de donnée d'abonnés résidentiels n'es pas centralisée
mais réparti selon un découpage régionnal spécifique à FT.
on ^parlait pas de cette base la, on parlait de "symphonie"
Un beau de jour, ou pour etre plus precis le 04/08/2005, Franck Yvonnet a déclamé dans le message le texte d'une qualité littéraire indéniable suivant :
Ainsi Parlait Michel Billaud
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de données ?
Justement, la base de donnée d'abonnés résidentiels n'es pas centralisée mais réparti selon un découpage régionnal spécifique à FT.
on ^parlait pas de cette base la, on parlait de "symphonie"
helios
"Michel Billaud" a écrit dans le message de news:
"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 ?
c'est aussi mon opinion la base oracle est naze mais ici certain "specialiste oracle" trouve que 29To c'est normal FT a acces direct a oracle comme prestataire pour sa base oracle donc il y a de forte chance que c'est oracle qui a creer la base
moi j'avais soutenu qu'il y a erreur et que c'etait 29Go et non To mais les oracles soutienne mordicus que c'est des To
"Michel Billaud" <billaud@labri.u-bordeaux.fr> a écrit dans le message de
news:7z7jf2su32.fsf@serveur5.labri.fr...
"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 ?
c'est aussi mon opinion la base oracle est naze mais ici certain
"specialiste oracle" trouve que 29To c'est normal FT a acces direct a oracle
comme prestataire pour sa base oracle donc il y a de forte chance que c'est
oracle qui a creer la base
moi j'avais soutenu qu'il y a erreur et que c'etait 29Go et non To mais les
oracles soutienne mordicus que c'est des To
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 ?
c'est aussi mon opinion la base oracle est naze mais ici certain "specialiste oracle" trouve que 29To c'est normal FT a acces direct a oracle comme prestataire pour sa base oracle donc il y a de forte chance que c'est oracle qui a creer la base
moi j'avais soutenu qu'il y a erreur et que c'etait 29Go et non To mais les oracles soutienne mordicus que c'est des To
helios
"Franck Yvonnet" a écrit dans le message de news:
Ainsi Parlait Michel Billaud
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base
de données ?
Justement, la base de donnée d'abonnés résidentiels n'es pas centralisée mais réparti selon un découpage régionnal spécifique à FT.
-- tu perds ton temps j'ai deja explique la 42c a ses messieurs mais il
contitue de divague sur la centralisation de donnees et autres delires "oraclien" style je connait pas les numero d'appel et d'appelle je geres des numero pas FT
"Franck Yvonnet" <fyvonnet@gmail.com> a écrit dans le message de
news:slrndf39u8.pp1.fyvonnet@gwyneth.glou.net...
Ainsi Parlait Michel Billaud <billaud@labri.u-bordeaux.fr>
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_
base
de données ?
Justement, la base de donnée d'abonnés résidentiels n'es pas centralisée
mais réparti selon un découpage régionnal spécifique à FT.
--
tu perds ton temps j'ai deja explique la 42c a ses messieurs mais il
contitue de divague sur la centralisation de donnees et autres delires
"oraclien" style je connait pas les numero d'appel et d'appelle je geres des
numero pas FT
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base
de données ?
Justement, la base de donnée d'abonnés résidentiels n'es pas centralisée mais réparti selon un découpage régionnal spécifique à FT.
-- tu perds ton temps j'ai deja explique la 42c a ses messieurs mais il
contitue de divague sur la centralisation de donnees et autres delires "oraclien" style je connait pas les numero d'appel et d'appelle je geres des numero pas FT
helios
"l'indien" a écrit dans le message de news:
On Wed, 03 Aug 2005 21:23:29 +0200, Michel Billaud wrote:
"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 ?
Je pense que ces gens là utilisent des mainframe et que Oracle n'est pas forcément très implanté dans ce milieu. Mais ce sont quand même des bases relationnelles (bien qu'il reste des bases hierarchiques "historiques", sur ces bouzins...), mais plus souvent des base IBM, Unisys, ...
les bases sont des base pick pour les impots, les caisse de retraite et FT
la base oracle symphonie concerne 0,4% de l'informatique de FT mais ils vont continuer a pretendre que oracle est l'informatique de FT
600 personne travail avec oracle 134400 avec pick universe
La taille des bases est souvent impressionnante, fatalement, quand les bases portent des infos sur des centaines de milliers voire des millions d'individus... Mais les bases des caisses de retraites ou des impots comportent généralement peu d'information pour chaque personne: une caisse de retraite a en général un record par individu et par an, sauf s'il change de boulot. C'est la même chose pour un salarié, dans la base des impôts. Par contre, chez FT, il y a une nouvelle entrée à chaque fois que le téléphone frémit, ça peut faire beaucoup, au final !
[...]
"l'indien" <l_indien_no_more_spams@magic.fr> a écrit dans le message de
news:pan.2005.08.03.23.47.19.563581@magic.fr...
On Wed, 03 Aug 2005 21:23:29 +0200, Michel Billaud wrote:
"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 ?
Je pense que ces gens là utilisent des mainframe et que Oracle n'est pas
forcément très implanté dans ce milieu.
Mais ce sont quand même des bases relationnelles (bien qu'il reste des
bases hierarchiques "historiques", sur ces bouzins...), mais plus souvent
des base IBM, Unisys, ...
les bases sont des base pick pour les impots, les caisse de retraite et FT
la base oracle symphonie concerne 0,4% de l'informatique de FT mais ils vont
continuer a pretendre que oracle est l'informatique de FT
600 personne travail avec oracle 134400 avec pick universe
La taille des bases est souvent impressionnante, fatalement,
quand les bases portent des infos sur des centaines de milliers voire des
millions d'individus...
Mais les bases des caisses de retraites ou des impots comportent
généralement peu d'information pour chaque personne: une caisse de
retraite a en général un record par individu et par an, sauf s'il change
de boulot. C'est la même chose pour un salarié, dans la base des impôts.
Par contre, chez FT, il y a une nouvelle entrée à chaque fois que le
téléphone frémit, ça peut faire beaucoup, au final !
On Wed, 03 Aug 2005 21:23:29 +0200, Michel Billaud wrote:
"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 ?
Je pense que ces gens là utilisent des mainframe et que Oracle n'est pas forcément très implanté dans ce milieu. Mais ce sont quand même des bases relationnelles (bien qu'il reste des bases hierarchiques "historiques", sur ces bouzins...), mais plus souvent des base IBM, Unisys, ...
les bases sont des base pick pour les impots, les caisse de retraite et FT
la base oracle symphonie concerne 0,4% de l'informatique de FT mais ils vont continuer a pretendre que oracle est l'informatique de FT
600 personne travail avec oracle 134400 avec pick universe
La taille des bases est souvent impressionnante, fatalement, quand les bases portent des infos sur des centaines de milliers voire des millions d'individus... Mais les bases des caisses de retraites ou des impots comportent généralement peu d'information pour chaque personne: une caisse de retraite a en général un record par individu et par an, sauf s'il change de boulot. C'est la même chose pour un salarié, dans la base des impôts. Par contre, chez FT, il y a une nouvelle entrée à chaque fois que le téléphone frémit, ça peut faire beaucoup, au final !
[...]
helios
"Michel Billaud" a écrit dans le message de news:
"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).
le "binaire portable" est un pseudo assembleur independant du matos
"Michel Billaud" <billaud@labri.u-bordeaux.fr> a écrit dans le message de
news:7zslxqrc8r.fsf@serveur5.labri.fr...
"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).
le "binaire portable" est un pseudo assembleur independant du matos
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).
le "binaire portable" est un pseudo assembleur independant du matos
helios
"Michel Billaud" a écrit dans le message de news:
"helios" writes:
Gerer la securite sur l'incompetance, c'est exactement cela et notre tres cher ami helios est la grande demonstration que ca fonctionne.
moi aussi je pourrait filer un compte admin Pick et effectivement tu aurais
bien du mal a faire quoi que se soit car a la difference des comptes users
le compte admin necessite de connaitre et une fois connecte tu te retrouverais devant un prompt et tu ne saurais
pas quoi rentrer
On n'imagine pas qu'il lise la doc ?
il peut lires la doc et trouver mais sans aides il va mettre du temp avant d'etre operationnel et le temp qu'il le soit il n'auras plus acces
"Michel Billaud" <billaud@labri.u-bordeaux.fr> a écrit dans le message de
news:7zacjypufq.fsf@serveur5.labri.fr...
"helios" <helios@com02.com> writes:
Gerer la securite sur l'incompetance, c'est exactement cela et notre
tres cher ami helios est la grande demonstration que ca fonctionne.
moi aussi je pourrait filer un compte admin Pick et effectivement tu
aurais
bien du mal a faire quoi que se soit car a la difference des comptes
users
le compte admin necessite de connaitre
et une fois connecte tu te retrouverais devant un prompt et tu ne
saurais
pas quoi rentrer
On n'imagine pas qu'il lise la doc ?
il peut lires la doc et trouver mais sans aides il va mettre du temp avant
d'etre operationnel et le temp qu'il le soit il n'auras plus acces
Gerer la securite sur l'incompetance, c'est exactement cela et notre tres cher ami helios est la grande demonstration que ca fonctionne.
moi aussi je pourrait filer un compte admin Pick et effectivement tu aurais
bien du mal a faire quoi que se soit car a la difference des comptes users
le compte admin necessite de connaitre et une fois connecte tu te retrouverais devant un prompt et tu ne saurais
pas quoi rentrer
On n'imagine pas qu'il lise la doc ?
il peut lires la doc et trouver mais sans aides il va mettre du temp avant d'etre operationnel et le temp qu'il le soit il n'auras plus acces
Vincent Bernat
OoO En cette matinée ensoleillée du jeudi 04 août 2005, vers 09:24, "helios" disait:
la base oracle symphonie concerne 0,4% de l'informatique de FT mais ils vont continuer a pretendre que oracle est l'informatique de FT
600 personne travail avec oracle 134400 avec pick universe
Alors que si c'était au prorata, il faudrait 53760 pour Oracle. Cela prouve bien que Pick est un vieux machin beaucoup trop compliqué et peu économique. -- BOFH excuse #293: You must've hit the wrong anykey.
OoO En cette matinée ensoleillée du jeudi 04 août 2005, vers 09:24,
"helios" <helios@com02.com> disait:
la base oracle symphonie concerne 0,4% de l'informatique de FT mais ils vont
continuer a pretendre que oracle est l'informatique de FT
600 personne travail avec oracle 134400 avec pick universe
Alors que si c'était au prorata, il faudrait 53760 pour Oracle. Cela
prouve bien que Pick est un vieux machin beaucoup trop compliqué et
peu économique.
--
BOFH excuse #293:
You must've hit the wrong anykey.
OoO En cette matinée ensoleillée du jeudi 04 août 2005, vers 09:24, "helios" disait:
la base oracle symphonie concerne 0,4% de l'informatique de FT mais ils vont continuer a pretendre que oracle est l'informatique de FT
600 personne travail avec oracle 134400 avec pick universe
Alors que si c'était au prorata, il faudrait 53760 pour Oracle. Cela prouve bien que Pick est un vieux machin beaucoup trop compliqué et peu économique. -- BOFH excuse #293: You must've hit the wrong anykey.
Laurent Martin
c'est aussi mon opinion la base oracle est naze mais ici certain "specialiste oracle" trouve que 29To c'est normal FT a acces direct a oracle
comme prestataire pour sa base oracle donc il y a de forte chance que c'est
oracle qui a creer la base
29To pour une base, ça peut être parfaitement normal, cela dépend de quoi il s'agit et comment on l'utilise... J'imagine que ce n'est pas une base de production mais un datawarehouse alimenté à partir de nombreuses autres bases... ...qui lui même sert à produire des datamarts sur lesquels les utilisateurs font des requêtes... Les datamarts sont peut-être même compris dans les 29To...
D'ailleurs, je doute fortement qu'avec 29To, ce soit la "plus grosse" base Oracle au monde... AMHA, il doit en exister de beaucoup plus grosses...
c'est aussi mon opinion la base oracle est naze mais ici certain
"specialiste oracle" trouve que 29To c'est normal FT a acces direct a
oracle
comme prestataire pour sa base oracle donc il y a de forte chance que
c'est
oracle qui a creer la base
29To pour une base, ça peut être parfaitement normal, cela dépend de quoi il
s'agit et comment on l'utilise...
J'imagine que ce n'est pas une base de production mais un datawarehouse
alimenté à partir de nombreuses autres bases...
...qui lui même sert à produire des datamarts sur lesquels les utilisateurs
font des requêtes... Les datamarts sont peut-être même compris dans les
29To...
D'ailleurs, je doute fortement qu'avec 29To, ce soit la "plus grosse" base
Oracle au monde... AMHA, il doit en exister de beaucoup plus grosses...
c'est aussi mon opinion la base oracle est naze mais ici certain "specialiste oracle" trouve que 29To c'est normal FT a acces direct a oracle
comme prestataire pour sa base oracle donc il y a de forte chance que c'est
oracle qui a creer la base
29To pour une base, ça peut être parfaitement normal, cela dépend de quoi il s'agit et comment on l'utilise... J'imagine que ce n'est pas une base de production mais un datawarehouse alimenté à partir de nombreuses autres bases... ...qui lui même sert à produire des datamarts sur lesquels les utilisateurs font des requêtes... Les datamarts sont peut-être même compris dans les 29To...
D'ailleurs, je doute fortement qu'avec 29To, ce soit la "plus grosse" base Oracle au monde... AMHA, il doit en exister de beaucoup plus grosses...
Franck Yvonnet
Ainsi Parlait Laurent Martin
D'ailleurs, je doute fortement qu'avec 29To, ce soit la "plus grosse" base Oracle au monde... AMHA, il doit en exister de beaucoup plus grosses...
Rien que chez FT d'ailleurs j'ai vu des serveurs connectés à une rangée entière de baies EMC Symmetrix dont une seul dépasse largement les 29To.
-- Franck Yvonnet I remember when trolls were fairy tale creatures who lived under bridges. Now homeless people live there and trolls live on Usenet.
Ainsi Parlait Laurent Martin <toto@toto.invalid>
D'ailleurs, je doute fortement qu'avec 29To, ce soit la "plus grosse" base
Oracle au monde... AMHA, il doit en exister de beaucoup plus grosses...
Rien que chez FT d'ailleurs j'ai vu des serveurs connectés à une rangée
entière de baies EMC Symmetrix dont une seul dépasse largement les 29To.
--
Franck Yvonnet <fyvonnet@gmail.com>
I remember when trolls were fairy tale creatures who lived under bridges.
Now homeless people live there and trolls live on Usenet.
D'ailleurs, je doute fortement qu'avec 29To, ce soit la "plus grosse" base Oracle au monde... AMHA, il doit en exister de beaucoup plus grosses...
Rien que chez FT d'ailleurs j'ai vu des serveurs connectés à une rangée entière de baies EMC Symmetrix dont une seul dépasse largement les 29To.
-- Franck Yvonnet I remember when trolls were fairy tale creatures who lived under bridges. Now homeless people live there and trolls live on Usenet.
Thierry Thomas
Mercredi 03 août 2005 à 23:47 GMT, l'indien a écrit :
Par contre, chez FT, il y a une nouvelle entrée à chaque fois que le téléphone frémit, ça peut faire beaucoup, au final !
Faut pas tout garder non plus, quand on peut. J'ai bossé chez FT sur une base Oracle / Linux qui justement collectait les tickets de chaque appel pour la facturation des entreprises. Si je me souviens bien, à l'époque, on récupérait ~2 Go / jour / base, mais on ne conservait les tickets en ligne que sur 2 mois glissants, et j'avais fait un pro*C qui faisait des cumuls, et seuls ces cumuls étaient archivés au delà des 2 mois. -- Th. Thomas.
Mercredi 03 août 2005 à 23:47 GMT, l'indien a écrit :
Par contre, chez FT, il y a une nouvelle entrée à chaque fois que le
téléphone frémit, ça peut faire beaucoup, au final !
Faut pas tout garder non plus, quand on peut.
J'ai bossé chez FT sur une base Oracle / Linux qui justement collectait
les tickets de chaque appel pour la facturation des entreprises. Si je
me souviens bien, à l'époque, on récupérait ~2 Go / jour / base, mais
on ne conservait les tickets en ligne que sur 2 mois glissants, et
j'avais fait un pro*C qui faisait des cumuls, et seuls ces cumuls
étaient archivés au delà des 2 mois.
--
Th. Thomas.
Mercredi 03 août 2005 à 23:47 GMT, l'indien a écrit :
Par contre, chez FT, il y a une nouvelle entrée à chaque fois que le téléphone frémit, ça peut faire beaucoup, au final !
Faut pas tout garder non plus, quand on peut. J'ai bossé chez FT sur une base Oracle / Linux qui justement collectait les tickets de chaque appel pour la facturation des entreprises. Si je me souviens bien, à l'époque, on récupérait ~2 Go / jour / base, mais on ne conservait les tickets en ligne que sur 2 mois glissants, et j'avais fait un pro*C qui faisait des cumuls, et seuls ces cumuls étaient archivés au delà des 2 mois. -- Th. Thomas.
