Re: [linux] CPU
de toute facon les grosses caisses avec pleins de CPU c'est pas interessant, ca coute chers et ca crashe tout le temps. Rien ne vaut un bon cluster de PC et ca dois marcher pour toutes les applications si elle est bien developee. On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Vincent Jamart wrote: > | Je suis d'accord avec Pascal sur le fait de laisser le scheduler organiser > | les process. J'avais fait quelques benchs sur un pSeries (Power4+) avec > | DLPAR et le fameux "CPU affinity" et ca donnait de moins obn resultats > | pour des databases. Par compte, c'est possible qu'en HPC ca change la > | donne mais la machine n'avait que 4CPU et 2 lpar. Seule celle en AIX 5.2 > | pouvait supporter cette option, l'autre en SLES8/Pseries ne m'offrait > | aucune option. > > Oui, normal, SLES8 est sur kernel 2.4. > > A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand nombre > de CPUs, c?d une douzaine > au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot > par lui-m?me (en tout cas > pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que > pour 4). > > - -- > ~ -o) Pascal Bleserhttp://guru.unixtech.be > ~ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > ~ _\_v The more things change, the more they stay insane. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 > bRXllixBVpOsP2gVnEaWfWk= > =F96M > -END PGP SIGNATURE- > ___ > Linux Mailing List - http://www.unixtech.be > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > Archives: http://www.mail-archive.com/linux@lists.unixtech.be > IRC: chat.unixtech.be:6667 - #unixtech -- -- -> Jean-Francois Dive --> [EMAIL PROTECTED] I think that God in creating Man somewhat overestimated his ability. -- Oscar Wilde ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] CPU
Jean-Francois Dive wrote: de toute facon les grosses caisses avec pleins de CPU c'est pas interessant, ca coute chers et ca crashe tout le temps. Un petit exemple ? Une machine 64 CPUs de 3 ans; pas possible de se passer du contrat de maintenance car il est utilisé régulièrement... La valeur annuelle de ce contrat de maintenance était suffisante pour acheter CHAQUE ANNEE plus de deux fois la puissance CPU, l'espace RAM, l'espace HD sous forme de calculateurs dual-XEONS standards (32 bits), facilement réparables, remplaçables en cas de panne (ou additionnables d'année en année) ou min une fois avec des Opterons (64 bits). Ok, pour interconnecter les noeuds à plus de 1Gb/s c'est plus cher mais quand même c'est bien plus souple, robuste et extensible comme solution ! A la limite, pas de contrat de maintenance : avec cet argent on achète du nouveau matériel chaque année (et on colle à la loi de Moore au lieu d'entretenir un vieux trigu) et on peut même se permettre de jeter froidement ce qui ne va plus, sans y regarder ;-) Bonne journée, Alain Rien ne vaut un bon cluster de PC et ca dois marcher pour toutes les applications si elle est bien developee. On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent Jamart wrote: | Je suis d'accord avec Pascal sur le fait de laisser le scheduler organiser | les process. J'avais fait quelques benchs sur un pSeries (Power4+) avec | DLPAR et le fameux "CPU affinity" et ca donnait de moins obn resultats | pour des databases. Par compte, c'est possible qu'en HPC ca change la | donne mais la machine n'avait que 4CPU et 2 lpar. Seule celle en AIX 5.2 | pouvait supporter cette option, l'autre en SLES8/Pseries ne m'offrait | aucune option. Oui, normal, SLES8 est sur kernel 2.4. A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand nombre de CPUs, c?d une douzaine au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot par lui-m?me (en tout cas pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que pour 4). - -- ~ -o) Pascal Bleserhttp://guru.unixtech.be ~ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ~ _\_v The more things change, the more they stay insane. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 bRXllixBVpOsP2gVnEaWfWk= =F96M -END PGP SIGNATURE- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech -- Dr Alain EMPAIN <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Bioinformatics, Molecular Genetics, Fac. Med. Vet., University of Liège, Belgium Bd de Colonster, B43 B-4000 Liège (Sart-Tilman) WORK: +32 4 366 3821 FAX: +32 4 366 4122 HOME: rue des Martyrs,7 B- 4550 Nandrin +32 85 51 23 41 GSM: +32 497 70 17 64 --- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur même de l'activité de création et d'invention. La connaissance scientifique est basée sur des siècles de partage créatif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html --- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] CPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alain EMPAIN wrote: | A la limite, pas de contrat de maintenance : avec cet argent on achète | du nouveau matériel chaque année (et on colle à la loi de Moore au lieu | d'entretenir un vieux trigu) et on peut même se permettre de jeter | froidement ce qui ne va plus, sans y regarder ;-) Quelle indécence... :o) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBmyP/3Qzx239StfYRAi13AJ0cDHcaz6kVJI0dl07+qMmT6PFXAgCgnDLx ArjziWOBBBR/jgBjnJrGEFo= =EFLf -END PGP SIGNATURE- -- The information contained in this electronic message may be legally privileged and confidential under applicable law, and is intended only for the use of the individual or entity named above. If the recipient of this message is not the above-named intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify Keyware, +32 2 526 16 16 and purge the communication immediately without making any copy or distribution. ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] CPU
Fabian Vilers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alain EMPAIN wrote: | A la limite, pas de contrat de maintenance : avec cet argent on achète | du nouveau matériel chaque année (et on colle à la loi de Moore au lieu | d'entretenir un vieux trigu) et on peut même se permettre de jeter | froidement ce qui ne va plus, sans y regarder ;-) Quelle indécence... :o) Tu penses bien que c'est mon genre... J'ai toujours un tournevis à deux lames sur moi ;-) Alain -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBmyP/3Qzx239StfYRAi13AJ0cDHcaz6kVJI0dl07+qMmT6PFXAgCgnDLx ArjziWOBBBR/jgBjnJrGEFo= =EFLf -END PGP SIGNATURE- -- The information contained in this electronic message may be legally privileged and confidential under applicable law, and is intended only for the use of the individual or entity named above. If the recipient of this message is not the above-named intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify Keyware, +32 2 526 16 16 and purge the communication immediately without making any copy or distribution. ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech -- Dr Alain EMPAIN <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Bioinformatics, Molecular Genetics, Fac. Med. Vet., University of Liège, Belgium Bd de Colonster, B43 B-4000 Liège (Sart-Tilman) WORK: +32 4 366 3821 FAX: +32 4 366 4122 HOME: rue des Martyrs,7 B- 4550 Nandrin +32 85 51 23 41 GSM: +32 497 70 17 64 --- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur même de l'activité de création et d'invention. La connaissance scientifique est basée sur des siècles de partage créatif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html --- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] CPU
Au boulot nous avons aussi ce genre de grÃÃsse machine, mais à part des disques et des ventilateurs et malgrà un dÃmÃnagement de quelques km et une perte soudaine du courant dans toute la salle des serveur, nous n'avons jamais rencontrà de problÃme hardware bloquant (aÃe, je ne devrais pas dire Ãa). Pour info nous utilisons du materiel ibm pSeries. Nous allons recevoir 2 nouveaux serveurs (p570) trÃs bientÃt. Question maintenance et support, c'est vrai Ãa coÃte un pont. Petite question: avez-vous dÃjà eu de mauvaises expÃrience et avec quel matÃriel ou quel fabriquant? Des anecdotes c'est toujours sympa. -- Thomas Le mercredi 17 novembre 2004 à 10:31 +0100, Alain EMPAIN a Ãcrit : > > Jean-Francois Dive wrote: > > de toute facon les grosses caisses avec pleins de CPU c'est pas > > interessant, ca coute chers et ca crashe tout le temps. > > Un petit exemple ? > > Une machine 64 CPUs de 3 ans; pas possible de se passer du contrat de > maintenance car il est utilisà rÃguliÃrement... > > La valeur annuelle de ce contrat de maintenance Ãtait suffisante pour > acheter CHAQUE ANNEE plus de deux fois la puissance CPU, l'espace RAM, > l'espace HD sous forme de calculateurs dual-XEONS standards (32 bits), > facilement rÃparables, remplaÃables en cas de panne (ou additionnables > d'annÃe en annÃe) ou min une fois avec des Opterons (64 bits). > > Ok, pour interconnecter les noeuds à plus de 1Gb/s c'est plus cher mais > quand mÃme c'est bien plus souple, robuste et extensible comme solution ! > > A la limite, pas de contrat de maintenance : avec cet argent on achÃte > du nouveau matÃriel chaque annÃe (et on colle à la loi de Moore au lieu > d'entretenir un vieux trigu) et on peut mÃme se permettre de jeter > froidement ce qui ne va plus, sans y regarder ;-) > > Bonne journÃe, > > Alain > > > > Rien ne vaut un > > bon cluster de PC et ca dois marcher pour toutes les applications si > > elle est bien developee. > > > > On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote: > > > >>-BEGIN PGP SIGNED MESSAGE- > >>Hash: SHA1 > >> > >>Vincent Jamart wrote: > >>| Je suis d'accord avec Pascal sur le fait de laisser le scheduler organiser > >>| les process. J'avais fait quelques benchs sur un pSeries (Power4+) avec > >>| DLPAR et le fameux "CPU affinity" et ca donnait de moins obn resultats > >>| pour des databases. Par compte, c'est possible qu'en HPC ca change la > >>| donne mais la machine n'avait que 4CPU et 2 lpar. Seule celle en AIX 5.2 > >>| pouvait supporter cette option, l'autre en SLES8/Pseries ne m'offrait > >>| aucune option. > >> > >>Oui, normal, SLES8 est sur kernel 2.4. > >> > >>A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand nombre > >>de CPUs, c?d une douzaine > >>au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot > >>par lui-m?me (en tout cas > >>pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que > >>pour 4). > >> > >>- -- > >>~ -o) Pascal Bleserhttp://guru.unixtech.be > >>~ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > >>~ _\_v The more things change, the more they stay insane. > >>-BEGIN PGP SIGNATURE- > >>Version: GnuPG v1.2.2 (GNU/Linux) > >> > >>iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 > >>bRXllixBVpOsP2gVnEaWfWk= > >>=F96M > >>-END PGP SIGNATURE- > >>___ > >>Linux Mailing List - http://www.unixtech.be > >>Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > >>Archives: http://www.mail-archive.com/linux@lists.unixtech.be > >>IRC: chat.unixtech.be:6667 - #unixtech > > > > > ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
[linux] [OT] hardware: modem SpeedTouch 510 ADSL power on ?
J'ai la possibilité d'avoir un Thomson SpeedTouch 510, au lieu de mon ancien Alcatel SpeedTouch... ok, plus récent, plus joli, d'origine en router DHCP, etc ... MAIS !!! L'ancien Alcatel avait un SWITCH power ! Le nouveau Thomson a un POUSSOIR power ! Différence ??? Ben simplement... en cas de power off (coupure de courant par ex...) l'Alcatel redémarrait automatiquement, alors que le Thomson reste Power Off ! Faudra que je descend à la cave (si je suis chez moi) pour réactiver le modem Thomson en cas de coupure de courant (orage, etc... c'est rare... mais c'est qd mm arrivé 2 fois depuis les vacances) Pas très génial pour des serveurs, si l'ADSL ne redémarre pas auto ... bon ok... yaka mettre une UPS ;-) mais qd mm ! Un truc ? Une modif pour forcer le Power On du modem ? Je n'ai pas trouvé d'option dans le setup (ça existe dans le setup des PC) et j'ai ouvert, pas trouvé de jumper "Power-On" dans le modem. :-( Et si je soude, et que je courcircuite (en permanence) le bouton power-on ? Je risque qque chose ? -- Didier --- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur même de l'activité de création et d'invention. La connaissance scientifique est basée sur des siècles de partage créatif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html --- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
[linux] Re: [OT] hardware: SpeedTouch 510 ADSL AUTO-power-on
Didier Misson wrote: J'ai la possibilité d'avoir un Thomson SpeedTouch 510, au lieu de mon ancien Alcatel SpeedTouch... ok, plus récent, plus joli, d'origine en router DHCP, etc ... MAIS !!! L'ancien Alcatel avait un SWITCH power ! Le nouveau Thomson a un POUSSOIR power ! Différence ??? Ben simplement... en cas de power off (coupure de courant par ex...) l'Alcatel redémarrait automatiquement, alors que le Thomson reste Power Off ! Faudra que je descend à la cave (si je suis chez moi) pour réactiver le modem Thomson en cas de coupure de courant (orage, etc... c'est rare... mais c'est qd mm arrivé 2 fois depuis les vacances) Pas très génial pour des serveurs, si l'ADSL ne redémarre pas auto ... bon ok... yaka mettre une UPS ;-) mais qd mm ! Un truc ? Une modif pour forcer le Power On du modem ? Je n'ai pas trouvé d'option dans le setup (ça existe dans le setup des PC) et j'ai ouvert, pas trouvé de jumper "Power-On" dans le modem. :-( Et si je soude, et que je courcircuite (en permanence) le bouton power-on ? Je risque qque chose ? euh... comme on dit tj... un ptit coup de Google avant de poser ses questions :o) Ben voilà, trouvé : En théorie, un simple condensateur soudé sur le bouton poussoir, et le Thomson 510 devrait démarrer tout seul... http://home.swiftdsl.com.au/~speed/misc/index.php?content=6 Bon, je verrai la suite... mais une capa de 10µF c'est vraiment pas la ruine ! -- Didier --- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur même de l'activité de création et d'invention. La connaissance scientifique est basée sur des siècles de partage créatif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html --- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] CPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Silvestre wrote: | Au boulot nous avons aussi ce genre de grÃÃsse machine, mais à part des | disques et des ventilateurs et malgrà un dÃmÃnagement de quelques km et | une perte soudaine du courant dans toute la salle des serveur, nous | n'avons jamais rencontrà de problÃme hardware bloquant (aÃe, je ne | devrais pas dire Ãa). Pour info nous utilisons du materiel ibm pSeries. | Nous allons recevoir 2 nouveaux serveurs (p570) trÃs bientÃt. | Question maintenance et support, c'est vrai Ãa coÃte un pont. | | Petite question: avez-vous dÃjà eu de mauvaises expÃrience et avec quel | matÃriel ou quel fabriquant? Des anecdotes c'est toujours sympa. Nous (ou nos clients) n'avons pas vraiment eu de mauvaises expÃriences cÃtà stabilità ou mÃme performance, pour autant que je sache en tout cas. Moi c'est plutÃt l'aspect du coÃt que je voulais mettre en avant. Et en fait c'est assez simple à argumenter (en dÃfaveur des "grosses" machines): dans 99% des cas, tout le monde a un besoin en performances qui est assez stable sur toute l'annÃe. Il y a des peaks en journÃe, ou bien la nuit, mais grossomodo, c'est mesurÃ, bien connu et puis on sait acheter une machine (ou plusieurs) en fonction de cela. Je vais prendre l'exemple d'un de nos clients, VISA. Pour VISA comme dans la trÃs grande majorità des cas, il y a plusieurs pÃriodes de peaks trÃs forts sur l'annÃe, comme p.ex. noÃl, pÃques, la pÃriode de vacances. Pendant ces pÃriodes-lÃ, tu as un besoin en performance qui est souvent 2 à 3 fois supÃrieur à ton maximum sur l'annÃe. Tout ceci pour expliquer que si tu prends pour stratÃgie d'utiliser une (ou deux) trÃs grosse(s) machine(s) (disons une Sun Enterprise 15000), tu es forcÃment obligà d'acheter une machine grosse assez pour supporter la charge _maximale_ en production sur toute l'annÃe. Or, elle va s'emmr le reste du temps. Si, par contre, tu choisis une stratÃgie avec beaucoup (ou du moins plusieurs) machines plus "petites" (comme dÃjà dit, pas nÃcessairement des P3 avec 256MB RAM non plus hein ;)) que tu utilises en cluster, tu gagnes: 1) en redondance: lorsque des composantes matÃrielles rendent l'Ãme, une autre machine reprend la charge (oui, je sais, ces "grosses" machines ont quand mÃme pas mal de composants en redondance (alimentation, ...) mais bon, quand mÃme - essaye de couper une E15K en deux pour la mettre sur 2 sites ;)) 2) en coÃts: lorsque tu as ces pÃriodes "chaudes" sur l'annÃe, tu ajoutes des machines pour gÃrer la charge - mais ces machines peuvent Ãtre utilisÃes pour d'autres applications le reste de l'annÃe 3) en maintenance: oui et non: ~ - tu y perds à moins d'avoir des bons systÃmes de gestion de cluster (gÃrer 30 machines est à priori plus complexe qu'en gÃrer une seule, mÃme partitionnÃe) ~ - tu y gagnes parce que quand tu veux augmenter la performance, tu ajoutes qqes machines (p.ex. Intel ou AMD + Linux) - avec ton E15K, une fois la capacità maximale atteinte, il faudra en acheter une 2Ãme (et bonjour les frais) NÃanmoins, j'ajouterais un bÃmol à ce que Jef à dit: c'est beaucoup plus complexe d'implÃmenter une application qui fonctionne bien en termes de "scalability" (+/- "parallÃlisation") et de "failover" qu'une application qui fonctionne simplement avec beaucoup de CPUs. Donc Ãa dÃpend parfois aussi du cas de figure, du type et de la qualità de l'implÃmentation (software). Un cluster de serveurs web (p.ex. Apache ou Tomcat), Ãa se gÃre trÃs facilement en cluster de beaucoup de petites machines. Par contre, quand il y a beaucoup d'accÃs DB et beaucoup de donnÃes à ~ gÃrer, c'est dÃjà nettement plus compliquà (synchronisation des sessions, des caches, Ãviter la sÃrialisation des accÃs DB, XA est une horreur, ...). Enfin, Ãa fait vivre les architectes systÃme comme moi ;D Il faut aussi voir que tu dois investir dans un bon backbone en fibre optique (ou myrinet) pour relier les noeuds (machines) du cluster. En outre, le consommation en Ãlectricità est beaucoup plus importante pour 50 machines que pour 1 grosse - Ãa n'est gÃnÃralement pas pris en compte, mais si tu prends le cas de Google (1 machines AMD/Intel+Linux) ou dÃs que tu comptes plusieurs centaines de "petites" machines ... Il y a du pour et du contre, mais personellement, je suis à priori beaucoup plus pour une infrastructure de cluster de petites machines. Un avantage Ãnorme, c'est aussi que tu as des composants "standards", cÃd du hardware sur base Intel, AMD (ou mÃme PowerPC) que tu peux acheter chez plusieurs revendeurs (Intel, HP, Dell, Sun, et beaucoup d'autres). Avec les trÃs grosses machines, tu n'as pas tellement le choix (IBM z- et s-Series, IBM p-Series, Sun Enterprise). enfin voilÃ, my 0.02EUR ;) - -- ~ -o) Pascal Bleserhttp://guru.unixtech.be ~ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ~ _\_v The more things change, the more they stay insane. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBn
