La recompilation se justifie encore aujourd'hui notamment pour retirer les trucs inutiles (voire dangereux) car, meme avec un systeme de modules a la mod_so, beaucoup de modules sont activés dans le "core".
De plus, certaines options sont encore definies au moment de la compilation et une configuration chez un hebergeur differe tres largement d'une machine personnelle.
Et pour finir, il y a tout interet a essayer de reduire la taille memoire du kernel, des executables puisque, chez un hebergeur, il y a souvent plethore de machines quasi identiques et donc, tout gain sera repercute sur l'ensemble du parc.
Cependant, je ne pense pas non plus que l'extreme du "je compile/personnalise tout" soit une bonne idee. Je dis qu'un hebergeur qui veut maitriser sa plateforme et essayer d'en tirer le maximum a tout interet a essayer de reduire le "gras" de certains services critiques et le temps perdu par la maintenance qui en decoule sera largement compensée par une connaissance et une maitrise accrues de ses outils (et l'efficacite qui en resultera).
[^] # Re: Trou de sécurité dans PHP 4.3.0
Posté par Ben A. . En réponse à la dépêche Trou de sécurité dans PHP 4.3.0. Évalué à 8.
De plus, certaines options sont encore definies au moment de la compilation et une configuration chez un hebergeur differe tres largement d'une machine personnelle.
Et pour finir, il y a tout interet a essayer de reduire la taille memoire du kernel, des executables puisque, chez un hebergeur, il y a souvent plethore de machines quasi identiques et donc, tout gain sera repercute sur l'ensemble du parc.
Cependant, je ne pense pas non plus que l'extreme du "je compile/personnalise tout" soit une bonne idee. Je dis qu'un hebergeur qui veut maitriser sa plateforme et essayer d'en tirer le maximum a tout interet a essayer de reduire le "gras" de certains services critiques et le temps perdu par la maintenance qui en decoule sera largement compensée par une connaissance et une maitrise accrues de ses outils (et l'efficacite qui en resultera).