>c'est une droite entre les deux intersections la ou le signal des émetteurs ont une puissance
égale:
mais du coup si on prolonge la droite en dehors du segment des deux intersections, le signal des émetteurs continue a être de même puissance ... je suppose donc que c'est une droite passant par les deux intersections, mais sans limites.
enfin bon, il faut un troisième cercle on a dit :-)
il n'a pas précisé comment il comptait les cpus :-)
mais tu as raison, il faut tenir compte des possibilités de traitement parallèle des cpus.
Sur Intel, il faut compter les cores, ce qui n'est pas lisible dans /proc/cpuinfo si on a des proc multithreadés... moi j'ai tendance a ne pas prendre en compte l'hyperthreading.
quelqu'un sait ce que vaut l'hyperthreading du nehalem ? est-ce aussi "moche" que le pentium ?
Autre erreur: si t'as 8 cores et qu'un seul d'entre eux est a 100%, ton appli est probablement en attente de CPU !!
la solution serait de la ré-écrire ou de lancer plusieurs instances en parallèle, ... ou de changer d'architecture matérielle (core plus rapide mais moins nombreux)
MySQL a beaucoup progressé en performance dans les dernières versions, dixit même certains articles sur ce site.
Quelle version de MySQL fait tu tourner ?
As-tu passé les requêtes que tu trouves lente a un "explain plan" ?
>Et comment fait-on pour ça ? (t'as une recette ?)
ben c'est supporté en standard par x11vnc. il faut configurer xinetd pour qu'il ecoute sur le port 5900 et passe la connexion a x11vnc avec des options pour lui dire d'utiliser le login/passwd unix, de changer de uid pour l'utilisateur qui vient de s'authentifier, et de lancer une session X si aucune n'existe.
C'est (mal) documenté sut le site de x11vnc ( http://www.karlrunge.com/x11vnc/ ), si tu as besoin d'exemples, j'en récupererai au boulot :-)
sauf si cela a changé, vncserver oblige a convenir d'un port TCP différent pour chaque utilisateur, et de définir un "mot de passe vnc" stocké dans un fichier ... beurk
x11vnc peut utiliser Xvnc pour créer des sessions X qui ne sont pas la session Xorg ( :0 ) du serveur, et l'utilisateur peut utiliser soit sa clef ssh, soit son mot de passe unix pour s'authentifier. De plus tous les displays crées peuvent être joignables sur le port vnc par défaut (5900) et donc plus besoin de convenir a l'avance d'un port particulier pour une personne. C'est quand même plus pratique !
x11vnc peut servir a donner acces a la session X11 existante (celle du serveur) à distance en vnc, mais il sait aussi servir des sessions. Les options de la ligne de commande sont touffues, mais on peut faire pas mal de choses.
Par exemple:
- ecoute sur le port tcp/5900 via xinetd (vnc standard) et demande de user+password graphiquement (en protocole vnc), puis changement d'uid pour lancer la session X11 qui sera accessible en vnc. Dans ce mode, on peut lui demander de ne pas tuer la session a la deconnection et de la récupérer quand le meme user revient. Tout ce qu'il faut sur le client c'est un client VNC.
- ou alors, l'utilisateur se connecte grace a sa clef ssh et le protocole VNC est tunnelé dans SSH. Dans ce mode, plus besoin de user+password et la aussi la session peut rester et etre recupérée. Pour utiliser ce mode, j'ai un peu instrumenté le .profile pour que la socket de liaison avec l'agent SSH ne change pas de nom a chaque session et du coup quand je me reconnecte, tous mes xterms et autres programmes déjà lancés récupèrent également la connection vers mon agent ssh (ma clef privée reste sur mon portable, pas question de la copier sur le serveur).
bref, on peut faire pas mal de choses. J'ai même utilisé le mode authentification ldap, et j'ai du envoyer un patch car il y a un bug quand on veut utiliser le mode xinetd et ldap.
je suis partiellement d'accord avec toi. les outils "acronymes" ne sont pas forcément plus compliqués et ne bouffent pas 500Mo de ram. De plus ils viennent avec une api qui fait bien plus qu'une simple copie de fichiers.
Avec la méthode "fichiers" il va falloir définir le format des fichiers (xml ? ascii ? ...) et puis décider quand on peut l'effacer (quand considère t'on qu'il a bien été traité en face ?), et puis mettre en place un compte applicatif avec une clef ssh sans passphrase (scp), mais alors on voudra le bloquer dans un sous répertoire pour sécuriser la machine (chroot ?) ou alors ne pas utiliser scp mais plutôt une commande associée a la clef ...
Et puis cela va marcher ... jusqu'au jour ou le contenu du fichier ne sera pas prévu par le parser écrit a-la-rache, et que l'import du fichier va foirer. mais comme c'est mal écrit le script ne sait pas remonter l'erreur, ni sauter le fichier qui pose problème, du coup il se bloque.
Alors on va décider d'ajouter du monitoring, de créer les sondes cacti qui vont avec, et on va de nouveau engager 15 jours/homme sur ce problème pour "ne pas utiliser d'acronymes".
Si le besoin est ultra simple (et cela semble le cas), scp peut-être la bonne méthode, mais moi j'en ai marre des usines a gaz commandées par des crontab qui se lancent toutes les minutes, et qui s'enchainent de serveur en serveur pour faire passer les informations. C'est rapide a mettre en place mais c'est rapidement la foire totale sur les machines.
tu veux un MOM ( Message Oriented Middleware).
c'est un logiciel qui gère l'envoi des informations entre deux autres logiciels avec une queue pour les garder en spool si la transmission immédiate n'est pas possible.
chez les editeurs IBM MQSeries, Tibco, ...
en plus libre: OpenJMS, ActiveMQ, ...
tu trouvera bien l'implémentation qui te plait le mieux sur le web
tu veux un middleware orienté message (MOM).
un MOM gère une queue de messages dans laquelle les informations sont stockées si la livraison immédiate n'est pas possible.
Il y a des produits commerciaux très connus (IBM MQSeries, tibco, ...).
tu peux te tourner vers JMS en java, ou activeMQ, ou ... tu trouvera bien l'implémentation qui te plait le mieux.
pour le web y'a des outils sympa qui génèrent des moyt de passe en fonction d'un password unique et du nom de domaine par exemple.
c'est implémenté en modules firefox, comme "password hasher" https://addons.mozilla.org/en-US/firefox/addon/3282
ça permet de ne retenir qu'un seul mot de passe pour les sites web.
Si tu as peur de charger le serveur avec tcpdump, tu peux sniffer a coté du client ... ce sera moins verbose et de toutes manières pas fait par le serveur.
Sinon avec un tcpdump -n -i interface port 67 or port 68 -s0 -w /tmp/matrace.dump tu vas enregistrer les paquets qui t'intéressent, et tu pourra ouvrir ce fichier avec wireshark (sous linux ou windows).
ben moi je passe plus de temps au boulot que sur mon pc perso ... donc 25%
cela dit, au boulot, on utilise des postes windows pour gérer des serveurs linux ... ça se compte comment ça ?
juste pour participer, avec mysql la réplication multi-maitre peut fonctionner, si ton application prend quelques mesures pour ne pas avoir de problèmes.
Une astuce est aussi de configurer chaque serveur pour qu'il génère des clef primaires qui n'entrent pas en conflit (par exemple un serveur génère des clefs "paires" et l'autre des clefs "impaires"). cela se fait dans mysql.ini
en fait le GROS problème de la réplication multi-maitre asynchrone est qu'en cas de crash il est extremement compliqué de garantir la restauration exhaustive de toutes les transactions en cours. la réplication asynchrone n'aide pas, et le multi maitre complique encore les choses. Quel backup garder ? comment etre sur d'avoir tous les journaux necessaires ? comment les rejouer après une restauration de serveur ?? bref c'est bien pour certaines applis mais compliqué a opérer correctement.
Posté par PLuG .
En réponse au message Antivirus.
Évalué à 1.
un autre soucis est aussi que Windows est capable d'etre infecté par tellement de saloperies différentes que clamav est loin de toutes les détecter ... J'en ai encore fait l'expérience récemment avec une clef USB sur laquelle un virus était présent, détecté par des antivirus sous windows, pas par clamav sous linux...
tout a fait, le nombre d'utilisateurs n'est pas limité arbitrairement dans les logiciels libres (pas de licence 253 users et pas un de plus), donc la limite va dépendre .... de ton utilisation, et tu ne trouvera pas l'information qui TE concerne sur les sites web.
La limite va dépendre de la puissance de ton hardware, du nombre de serveurs, mais surtout de l'architecture logicielle utilisée et de la qualité des algorithmes utilisés.
La plupart du temps un problème de performance peut être résolu avec des améliorations algorithmiques ou architecturales qui permettent de passer avec le même hardware ... (mais c'est plus cher que de changer le hardware ou d'ajouter des serveurs alors souvent on ajoute du hardware :-)).
Bref Eric ci dessus a raison, utilise l'outil qui est déjà le plus utilisé par les entreprises et pour lequel tu aura le plus de doc et le meilleur support de la communauté (et de SSII pourquoi pas).
contrairement a RAID qui améliore la disponibilité du stockage sur disque mais ne prémuni pas des erreurs humaines, "time machine" permet de se protéger de certaines erreurs humaines (mais pas de toutes), mais ne fait rien pour protéger d'une panne disque.
Les deux ne sont pas de vraies sauvegardes externalisables et protégeant contre le vol de matériel ou les catastrophes (incendie, inondation, ...)
et surtout RAID n'est pas un mécanisme de sauvegarde, c'est un procédé qui permet d'améliorer la fiabilité du stockage disque. Si tu balance un "rm -rf * " dans ton home directory, RAID va gentiment le faire sur les n copies mirrorées puisque c'est son rôle.
Avec une sauvegarde, tu as une copie que tu espère pas trop ancienne des données, sur un média différent, que tu peux stocker dans un lieu volontairement distant pour te prémunir
aussi des dégats matériels (incendie, inondation, foudre, ...) ou même des vols de matériel
(si pendant tes congés tu te fais piquer ton PC avec tes 2 disques en RAID ... ben t'as tout perdu).
si si c'est pertinent, mais c'est une autre approche.
Ce que tu cherche a éviter s'appele "split brain" en technologie cluster (les 2 sont actifs) et cela arrive parce que le protocole/la méthode pour que les 2 nodes du clusters négocie leur état ne fonctionne plus, du coup comme ils ne se "voient" plus l'un/l'autre ils deviennent master tous les deux.
En réseau en général on s'en fou un peu. Par exemple si un switch dégage, que le routeur connecté dessus devienne master n'est pas grâve puisque les machines ne pourront pas le joindre (a cause de la panne du switch).
Par contre en technologie de cluster c'est gravissime, l'application devient active des deux cotés et les données peuvent être complètement détruites (montage d'un même filesystème en ecriture par les deux nodes simultanément, ...). Du coup pour les clusters, la méthode est de rendre ce "protocole" de communication entre les deux clusters vraiment fiable, impossible de le faire tomber en panne.
Heartbeat implémente ça, en multipliant les liaisons (reseau, séries, ...) entre tes deux machines. Dans ton cas avec des parefeux, tu pourrais utiliser plusieurs cartes réseau connectées sur plusieurs switchs eux même reliés entre eux avec plusieurs trunks ... et ajouter une liaison série "au cas ou". La cela devient autement improbable de passer en "split brain".
Intégrer un logiciel existant ... ça demande pas mal de travail, surtout si c'est fait dans les règles de l'art de l'entreprise cliente, et selon ses procédures ...
Ca coute beaucoup plus qu'un téléphone !! et cela même si y'a presque rien à développer.
Du coup je trouve cette annonce pas sérieuse, ça doit être un fake ... mince je me suis fait prendre.
Dans la pratique ce n'est pas l'inverse, il n'y a pas de support SAN ESS IBM dans les distributions centos. D'ailleurs c'est compliqué car si on prend le driver fourni par redhat on a le support de redhat (mais pas de IBM qui demande de mettre le sien) et si on met le driver de IBM on a des difficultées avec le support de redhat ....
Si on ajoute que IBM ne livre de toutes façons pas de RPMs dudit driver et que si on suit le manuel d'installation il faudrait avoir gcc sur le serveur pour compiler le driver en local ... c'est très crado.
Donc nous on utilise centos, on package en RPM les drivers d'IBM (ou on utilise celui de la distribution), bref on fait notre sauce ... et on a de toutes façons pas de support (ni IBM ni RedHat).
Ca c'est très faisable sur une débian ou une gentoo si t'en as envie. Pour nous l'interêt de centos c'est qu'on a l'habitude de packager en RPM, qu'on a des dépots yum, et qu'on a "l'habitude" des distributions redhat. Mais dans la pratique on aurait pu migrer tout ça en debian ... c'est juste plus cher que de passer à centos (puisque identique a redhat).
[^] # Re: Alors moi j'ai des fortunes.
Posté par PLuG . En réponse au journal ha le php et ses élites. Évalué à 3.
[^] # Re: Pas que le GPS
Posté par PLuG . En réponse à la dépêche Votre smartphone est-t-il un mouchard en puissance ?. Évalué à 2.
égale:
mais du coup si on prolonge la droite en dehors du segment des deux intersections, le signal des émetteurs continue a être de même puissance ... je suppose donc que c'est une droite passant par les deux intersections, mais sans limites.
enfin bon, il faut un troisième cercle on a dit :-)
[^] # Re: Dimensionnement
Posté par PLuG . En réponse au message "load average" et dimensionnement d'un serveur. Évalué à 3.
mais tu as raison, il faut tenir compte des possibilités de traitement parallèle des cpus.
Sur Intel, il faut compter les cores, ce qui n'est pas lisible dans /proc/cpuinfo si on a des proc multithreadés... moi j'ai tendance a ne pas prendre en compte l'hyperthreading.
quelqu'un sait ce que vaut l'hyperthreading du nehalem ? est-ce aussi "moche" que le pentium ?
Autre erreur: si t'as 8 cores et qu'un seul d'entre eux est a 100%, ton appli est probablement en attente de CPU !!
la solution serait de la ré-écrire ou de lancer plusieurs instances en parallèle, ... ou de changer d'architecture matérielle (core plus rapide mais moins nombreux)
[^] # Re: Pas que le GPS
Posté par PLuG . En réponse à la dépêche Votre smartphone est-t-il un mouchard en puissance ?. Évalué à 5.
[^] # Re: Presse papier
Posté par PLuG . En réponse à la dépêche Revue de presse de l'April pour la semaine 40. Évalué à 2.
# quelle version ?
Posté par PLuG . En réponse au message Comparaison SGBDR. Évalué à 2.
Quelle version de MySQL fait tu tourner ?
As-tu passé les requêtes que tu trouves lente a un "explain plan" ?
[^] # Re: vnc
Posté par PLuG . En réponse au message Équivalent de GNU Screen pour une session X. Évalué à 3.
ben c'est supporté en standard par x11vnc. il faut configurer xinetd pour qu'il ecoute sur le port 5900 et passe la connexion a x11vnc avec des options pour lui dire d'utiliser le login/passwd unix, de changer de uid pour l'utilisateur qui vient de s'authentifier, et de lancer une session X si aucune n'existe.
C'est (mal) documenté sut le site de x11vnc ( http://www.karlrunge.com/x11vnc/ ), si tu as besoin d'exemples, j'en récupererai au boulot :-)
[^] # Re: vnc
Posté par PLuG . En réponse au message Équivalent de GNU Screen pour une session X. Évalué à 2.
x11vnc peut utiliser Xvnc pour créer des sessions X qui ne sont pas la session Xorg ( :0 ) du serveur, et l'utilisateur peut utiliser soit sa clef ssh, soit son mot de passe unix pour s'authentifier. De plus tous les displays crées peuvent être joignables sur le port vnc par défaut (5900) et donc plus besoin de convenir a l'avance d'un port particulier pour une personne. C'est quand même plus pratique !
[^] # Re: vnc
Posté par PLuG . En réponse au message Équivalent de GNU Screen pour une session X. Évalué à 4.
x11vnc peut servir a donner acces a la session X11 existante (celle du serveur) à distance en vnc, mais il sait aussi servir des sessions. Les options de la ligne de commande sont touffues, mais on peut faire pas mal de choses.
Par exemple:
- ecoute sur le port tcp/5900 via xinetd (vnc standard) et demande de user+password graphiquement (en protocole vnc), puis changement d'uid pour lancer la session X11 qui sera accessible en vnc. Dans ce mode, on peut lui demander de ne pas tuer la session a la deconnection et de la récupérer quand le meme user revient. Tout ce qu'il faut sur le client c'est un client VNC.
- ou alors, l'utilisateur se connecte grace a sa clef ssh et le protocole VNC est tunnelé dans SSH. Dans ce mode, plus besoin de user+password et la aussi la session peut rester et etre recupérée. Pour utiliser ce mode, j'ai un peu instrumenté le .profile pour que la socket de liaison avec l'agent SSH ne change pas de nom a chaque session et du coup quand je me reconnecte, tous mes xterms et autres programmes déjà lancés récupèrent également la connection vers mon agent ssh (ma clef privée reste sur mon portable, pas question de la copier sur le serveur).
bref, on peut faire pas mal de choses. J'ai même utilisé le mode authentification ldap, et j'ai du envoyer un patch car il y a un bug quand on veut utiliser le mode xinetd et ldap.
[^] # Re: un MOM
Posté par PLuG . En réponse au message Liaison réseau "tamponnée". Évalué à 4.
Avec la méthode "fichiers" il va falloir définir le format des fichiers (xml ? ascii ? ...) et puis décider quand on peut l'effacer (quand considère t'on qu'il a bien été traité en face ?), et puis mettre en place un compte applicatif avec une clef ssh sans passphrase (scp), mais alors on voudra le bloquer dans un sous répertoire pour sécuriser la machine (chroot ?) ou alors ne pas utiliser scp mais plutôt une commande associée a la clef ...
Et puis cela va marcher ... jusqu'au jour ou le contenu du fichier ne sera pas prévu par le parser écrit a-la-rache, et que l'import du fichier va foirer. mais comme c'est mal écrit le script ne sait pas remonter l'erreur, ni sauter le fichier qui pose problème, du coup il se bloque.
Alors on va décider d'ajouter du monitoring, de créer les sondes cacti qui vont avec, et on va de nouveau engager 15 jours/homme sur ce problème pour "ne pas utiliser d'acronymes".
Si le besoin est ultra simple (et cela semble le cas), scp peut-être la bonne méthode, mais moi j'en ai marre des usines a gaz commandées par des crontab qui se lancent toutes les minutes, et qui s'enchainent de serveur en serveur pour faire passer les informations. C'est rapide a mettre en place mais c'est rapidement la foire totale sur les machines.
[^] # Re: un MOM
Posté par PLuG . En réponse au message Liaison réseau "tamponnée". Évalué à 2.
mon premier post n'apparaissait pas j'ai cru que Firefox l'avait avalé tout cru !
désolé !
# un MOM
Posté par PLuG . En réponse au message Liaison réseau "tamponnée". Évalué à 3.
c'est un logiciel qui gère l'envoi des informations entre deux autres logiciels avec une queue pour les garder en spool si la transmission immédiate n'est pas possible.
chez les editeurs IBM MQSeries, Tibco, ...
en plus libre: OpenJMS, ActiveMQ, ...
tu trouvera bien l'implémentation qui te plait le mieux sur le web
# un MOM
Posté par PLuG . En réponse au message Liaison réseau "tamponnée". Évalué à 2.
un MOM gère une queue de messages dans laquelle les informations sont stockées si la livraison immédiate n'est pas possible.
Il y a des produits commerciaux très connus (IBM MQSeries, tibco, ...).
tu peux te tourner vers JMS en java, ou activeMQ, ou ... tu trouvera bien l'implémentation qui te plait le mieux.
[^] # Re: sauf que
Posté par PLuG . En réponse au journal Carte pour mot de passe. Évalué à 1.
c'est implémenté en modules firefox, comme "password hasher" https://addons.mozilla.org/en-US/firefox/addon/3282
ça permet de ne retenir qu'un seul mot de passe pour les sites web.
# tcpdump coté client
Posté par PLuG . En réponse au message Log des messages DHCP. Évalué à 1.
Sinon avec un
tcpdump -n -i interface port 67 or port 68 -s0 -w /tmp/matrace.dumptu vas enregistrer les paquets qui t'intéressent, et tu pourra ouvrir ce fichier avec wireshark (sous linux ou windows).[^] # Re: Le boulot...
Posté par PLuG . En réponse au sondage J'utilise Linux $n de mon temps. $n =. Évalué à 4.
cela dit, au boulot, on utilise des postes windows pour gérer des serveurs linux ... ça se compte comment ça ?
# conflits sur clef auto incrémentée
Posté par PLuG . En réponse au journal Réplication de BDD multi-maître asynchrône.. Évalué à 7.
Une astuce est aussi de configurer chaque serveur pour qu'il génère des clef primaires qui n'entrent pas en conflit (par exemple un serveur génère des clefs "paires" et l'autre des clefs "impaires"). cela se fait dans mysql.ini
server-id = 1
auto-increment-increment = 2
auto-increment-offset = 1
server-id = 1
auto-increment-increment = 2
auto-increment-offset = 2
en fait le GROS problème de la réplication multi-maitre asynchrone est qu'en cas de crash il est extremement compliqué de garantir la restauration exhaustive de toutes les transactions en cours. la réplication asynchrone n'aide pas, et le multi maitre complique encore les choses. Quel backup garder ? comment etre sur d'avoir tous les journaux necessaires ? comment les rejouer après une restauration de serveur ?? bref c'est bien pour certaines applis mais compliqué a opérer correctement.
[^] # Re: intéressant
Posté par PLuG . En réponse au message Antivirus. Évalué à 1.
[^] # Re: Autres axes
Posté par PLuG . En réponse au message Serveur d'application J2EE. Évalué à 3.
La limite va dépendre de la puissance de ton hardware, du nombre de serveurs, mais surtout de l'architecture logicielle utilisée et de la qualité des algorithmes utilisés.
La plupart du temps un problème de performance peut être résolu avec des améliorations algorithmiques ou architecturales qui permettent de passer avec le même hardware ... (mais c'est plus cher que de changer le hardware ou d'ajouter des serveurs alors souvent on ajoute du hardware :-)).
Bref Eric ci dessus a raison, utilise l'outil qui est déjà le plus utilisé par les entreprises et pour lequel tu aura le plus de doc et le meilleur support de la communauté (et de SSII pourquoi pas).
[^] # Re: Time Machine
Posté par PLuG . En réponse au sondage Je réalise mes sauvegardes avec. Évalué à 1.
Les deux ne sont pas de vraies sauvegardes externalisables et protégeant contre le vol de matériel ou les catastrophes (incendie, inondation, ...)
[^] # Re: Et RAID?
Posté par PLuG . En réponse au sondage Je réalise mes sauvegardes avec. Évalué à 6.
Avec une sauvegarde, tu as une copie que tu espère pas trop ancienne des données, sur un média différent, que tu peux stocker dans un lieu volontairement distant pour te prémunir
aussi des dégats matériels (incendie, inondation, foudre, ...) ou même des vols de matériel
(si pendant tes congés tu te fais piquer ton PC avec tes 2 disques en RAID ... ben t'as tout perdu).
[^] # Re: heartbeat
Posté par PLuG . En réponse au message Keepalived / VRRP et question réseau. Évalué à 1.
Ce que tu cherche a éviter s'appele "split brain" en technologie cluster (les 2 sont actifs) et cela arrive parce que le protocole/la méthode pour que les 2 nodes du clusters négocie leur état ne fonctionne plus, du coup comme ils ne se "voient" plus l'un/l'autre ils deviennent master tous les deux.
En réseau en général on s'en fou un peu. Par exemple si un switch dégage, que le routeur connecté dessus devienne master n'est pas grâve puisque les machines ne pourront pas le joindre (a cause de la panne du switch).
Par contre en technologie de cluster c'est gravissime, l'application devient active des deux cotés et les données peuvent être complètement détruites (montage d'un même filesystème en ecriture par les deux nodes simultanément, ...). Du coup pour les clusters, la méthode est de rendre ce "protocole" de communication entre les deux clusters vraiment fiable, impossible de le faire tomber en panne.
Heartbeat implémente ça, en multipliant les liaisons (reseau, séries, ...) entre tes deux machines. Dans ton cas avec des parefeux, tu pourrais utiliser plusieurs cartes réseau connectées sur plusieurs switchs eux même reliés entre eux avec plusieurs trunks ... et ajouter une liaison série "au cas ou". La cela devient autement improbable de passer en "split brain".
[^] # Re: j'ai pas lu, mais un peu testé
Posté par PLuG . En réponse à la dépêche Test de la Fedora 11 Leonidas. Évalué à 1.
# du travail pour un téléphone ??
Posté par PLuG . En réponse au message Logiciel de planning + conseils (+ développement ?). Évalué à 2.
Ca coute beaucoup plus qu'un téléphone !! et cela même si y'a presque rien à développer.
Du coup je trouve cette annonce pas sérieuse, ça doit être un fake ... mince je me suis fait prendre.
[^] # Re: Centos
Posté par PLuG . En réponse à la dépêche Red Hat Enterprise Linux 4.8. Évalué à 2.
Si on ajoute que IBM ne livre de toutes façons pas de RPMs dudit driver et que si on suit le manuel d'installation il faudrait avoir gcc sur le serveur pour compiler le driver en local ... c'est très crado.
Donc nous on utilise centos, on package en RPM les drivers d'IBM (ou on utilise celui de la distribution), bref on fait notre sauce ... et on a de toutes façons pas de support (ni IBM ni RedHat).
Ca c'est très faisable sur une débian ou une gentoo si t'en as envie. Pour nous l'interêt de centos c'est qu'on a l'habitude de packager en RPM, qu'on a des dépots yum, et qu'on a "l'habitude" des distributions redhat. Mais dans la pratique on aurait pu migrer tout ça en debian ... c'est juste plus cher que de passer à centos (puisque identique a redhat).