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
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 Linux sur un as400 risc, NetBSD doit aussi pouvoir y tourner.
NetBSD tourne sous DEC et AS400
-+- Helios in GLP - Mais non, c'est cohérent.... -+-
Vous n'avez pas l'impression de dire un peu tout et son contraire ? Le nombre d'incohenrence entre vos messages entre: ca fait ci, et ca fait ca avec ci et ca incompatibles, c'est énorme.
Il a ptêt un peu forcé sur la citronnelle de Java.
MN
-- 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)
Nicolas Le Scouarnec <root@india.ath.cx. nospam. invalid> writes:
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400
Linux sur un as400 risc, NetBSD doit aussi pouvoir y tourner.
NetBSD tourne sous DEC et AS400
-+- Helios in GLP - Mais non, c'est cohérent.... -+-
Vous n'avez pas l'impression de dire un peu tout et son contraire ? Le
nombre d'incohenrence entre vos messages entre: ca fait ci, et ca fait
ca avec ci et ca incompatibles, c'est énorme.
Il a ptêt un peu forcé sur la citronnelle de Java.
MN
--
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)
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 Linux sur un as400 risc, NetBSD doit aussi pouvoir y tourner.
NetBSD tourne sous DEC et AS400
-+- Helios in GLP - Mais non, c'est cohérent.... -+-
Vous n'avez pas l'impression de dire un peu tout et son contraire ? Le nombre d'incohenrence entre vos messages entre: ca fait ci, et ca fait ca avec ci et ca incompatibles, c'est énorme.
Il a ptêt un peu forcé sur la citronnelle de Java.
MN
-- 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:
Les bases de données relationnelles étaient pressenties dans les années 1970 comme remplaçants des fichiers classiques
non non.
Les bases de données réseau (genre CODASYL) ont étendu les hiérarchiques qui remplaçaient les fichiers genre indexé / sequentiel-indexé.
C'est au milieu des années 80 que l' "industrie" a commencé à prendre au sérieux les élucubrations des universitaires et autre gauchistes chevelus drogués irresponsables des labos de recherche concernant les bases de données relationnelles. Jusque là, elle préssentait que rien ne remplacerait un bon produit fiable et performant comme IMS.
http://www.nap.edu/readingroom/books/far/ch6.html
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 bases de données relationnelles étaient pressenties dans les années 1970
comme remplaçants des fichiers classiques
non non.
Les bases de données réseau (genre CODASYL) ont étendu les hiérarchiques
qui remplaçaient les fichiers genre indexé / sequentiel-indexé.
C'est au milieu des années 80 que l' "industrie" a commencé à prendre
au sérieux les élucubrations des universitaires et autre gauchistes
chevelus drogués irresponsables des labos de recherche concernant les
bases de données relationnelles. Jusque là, elle préssentait que rien
ne remplacerait un bon produit fiable et performant comme IMS.
http://www.nap.edu/readingroom/books/far/ch6.html
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 bases de données relationnelles étaient pressenties dans les années 1970 comme remplaçants des fichiers classiques
non non.
Les bases de données réseau (genre CODASYL) ont étendu les hiérarchiques qui remplaçaient les fichiers genre indexé / sequentiel-indexé.
C'est au milieu des années 80 que l' "industrie" a commencé à prendre au sérieux les élucubrations des universitaires et autre gauchistes chevelus drogués irresponsables des labos de recherche concernant les bases de données relationnelles. Jusque là, elle préssentait que rien ne remplacerait un bon produit fiable et performant comme IMS.
http://www.nap.edu/readingroom/books/far/ch6.html
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
"JustMe" writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de donné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)
"JustMe" <pasdespam@merci.beaucoup> writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base
de donné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 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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de donné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:
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 ?
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:
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 ?
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)
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 ?
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:
Vincent Bernat wrote:
Mais bon, être un cancre en maths ne préjuge pas de vos connaissances sur PICK. Vous passez juste pour un clown.
N'empeche que passer pour un clown en decrivant un logiciel que personne ne connait, c'est quand meme tres fort.
Ca s'arrose. C'est ma tournée de citronnelle de java, tiens.
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:
Vincent Bernat wrote:
Mais bon, être un cancre en maths ne préjuge pas de vos connaissances
sur PICK. Vous passez juste pour un clown.
N'empeche que passer pour un clown en decrivant un logiciel que personne
ne connait, c'est quand meme tres fort.
Ca s'arrose. C'est ma tournée de citronnelle de java, tiens.
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)
Mais bon, être un cancre en maths ne préjuge pas de vos connaissances sur PICK. Vous passez juste pour un clown.
N'empeche que passer pour un clown en decrivant un logiciel que personne ne connait, c'est quand meme tres fort.
Ca s'arrose. C'est ma tournée de citronnelle de java, tiens.
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)
Stéphane CARPENTIER
Michel Billaud wrote:
"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.
Heu, non. J'espère que pour gérer la plus grosse base Oracle au monde, il y a plusieurs administrateurs. A la limite, deux administrateurs qui se relaient le jour et l'un des deux qui est de garde la nuit. Et un troisième administrateur pour que les deux premiers puissent prendre des vacances.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Michel Billaud wrote:
"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.
Heu, non. J'espère que pour gérer la plus grosse base Oracle au monde,
il y a plusieurs administrateurs. A la limite, deux administrateurs
qui se relaient le jour et l'un des deux qui est de garde la nuit. Et
un troisième administrateur pour que les deux premiers puissent prendre
des vacances.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
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.
Heu, non. J'espère que pour gérer la plus grosse base Oracle au monde, il y a plusieurs administrateurs. A la limite, deux administrateurs qui se relaient le jour et l'un des deux qui est de garde la nuit. Et un troisième administrateur pour que les deux premiers puissent prendre des vacances.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
l'indien
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, ...
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" <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, ...
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, ...
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
On Wed, 03 Aug 2005 23:32:10 +0200, Michel Billaud wrote:
"JustMe" writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de données ?
C'est loin d'être illogique: il faut pouvoir retrouver en interrogeant la base toute l'information requise. Si les données sont éclatées entre plusieurs bases, bonjour la galère. Sans compter que s'il y a plusieurs bases, il faut gérer soi même la cohérence et les relations entre les bases alors que le SGBDR le fait tout seul à l'intérieur d'une base.
Par contre, la base en question contient peut-être des milliers de tables...
On Wed, 03 Aug 2005 23:32:10 +0200, Michel Billaud wrote:
"JustMe" <pasdespam@merci.beaucoup> writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base
de données ?
C'est loin d'être illogique: il faut pouvoir retrouver en interrogeant
la base toute l'information requise. Si les données sont éclatées entre
plusieurs bases, bonjour la galère. Sans compter que s'il y a plusieurs
bases, il faut gérer soi même la cohérence et les relations entre les
bases alors que le SGBDR le fait tout seul à l'intérieur d'une base.
Par contre, la base en question contient peut-être des milliers de
tables...
On Wed, 03 Aug 2005 23:32:10 +0200, Michel Billaud wrote:
"JustMe" writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de données ?
C'est loin d'être illogique: il faut pouvoir retrouver en interrogeant la base toute l'information requise. Si les données sont éclatées entre plusieurs bases, bonjour la galère. Sans compter que s'il y a plusieurs bases, il faut gérer soi même la cohérence et les relations entre les bases alors que le SGBDR le fait tout seul à l'intérieur d'une base.
Par contre, la base en question contient peut-être des milliers de tables...
JustMe
l'indien a exposé le 04/08/2005 :
On Wed, 03 Aug 2005 23:32:10 +0200, Michel Billaud wrote:
"JustMe" writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de données ?
C'est loin d'être illogique: il faut pouvoir retrouver en interrogeant la base toute l'information requise. Si les données sont éclatées entre plusieurs bases, bonjour la galère. Sans compter que s'il y a plusieurs bases, il faut gérer soi même la cohérence et les relations entre les bases alors que le SGBDR le fait tout seul à l'intérieur d'une base.
tout a fait. Par exemple dans le cas ou on ne connais pas le No FT correspondant à l'appel ou une division géographique des données rendrait la recherche quasi impossible.
l'indien a exposé le 04/08/2005 :
On Wed, 03 Aug 2005 23:32:10 +0200, Michel Billaud wrote:
"JustMe" <pasdespam@merci.beaucoup> writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base
de données ?
C'est loin d'être illogique: il faut pouvoir retrouver en interrogeant
la base toute l'information requise. Si les données sont éclatées entre
plusieurs bases, bonjour la galère. Sans compter que s'il y a plusieurs
bases, il faut gérer soi même la cohérence et les relations entre les
bases alors que le SGBDR le fait tout seul à l'intérieur d'une base.
tout a fait. Par exemple dans le cas ou on ne connais pas le No FT
correspondant à l'appel ou une division géographique des données
rendrait la recherche quasi impossible.
On Wed, 03 Aug 2005 23:32:10 +0200, Michel Billaud wrote:
"JustMe" writes:
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.
Certes certes, et pourquoi tout ce merdier est-il centralisé sur _une_ base de données ?
C'est loin d'être illogique: il faut pouvoir retrouver en interrogeant la base toute l'information requise. Si les données sont éclatées entre plusieurs bases, bonjour la galère. Sans compter que s'il y a plusieurs bases, il faut gérer soi même la cohérence et les relations entre les bases alors que le SGBDR le fait tout seul à l'intérieur d'une base.
tout a fait. Par exemple dans le cas ou on ne connais pas le No FT correspondant à l'appel ou une division géographique des données rendrait la recherche quasi impossible.
Franck Yvonnet
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.
-- 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 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.
--
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.
