> Qu'est ce que tu gagnes a utiliser ulimit? la garantie qu'un fork bomb ne marchera pas.
> Qu'est ce que tu perds a utiliser ulimit? rien.
J'ai répondu à ça plus haut.
> mais j'ai l'impression que ce que t'as pas compris, c'est que, justement, le boulot de l'admin, ben c'est que ce genre de choses ca arrive pas.
Et ça t'est arrivé combien de fois sur des postes desktop ?
0 ou 1 fois ?
Et les conséquences ? Un reboot. Mais tu as vu combien de reboot "sauvage" (non désiré), de reset à cause d'un nouveau noyau qui a un driver qui sucks, ou à cause d'un problème hardware (une carte mal insérée, etc) ou de coupure de courant ? 1000 et peut-être probablement plus.
Si tu es préoccupé par les reboots "sauvage", je te comprend. Mais il y bien autres chose a faire avant de regarder du côté d'ulimit. Et tu configures ulimit pour que les fork bomb soient anodins, tu seras emmerdé par quelques utilisateurs qui font une utilisation un poil poussé de linux. Ils vont perdre du temps, tu vas perdre du temps pour finalement virer ou du moins atténué ulimit (ce qui probablement ne te mettra plus à l'apris d'un fork bomb). Et ça pour quoi ? Pour éviter au mieux 0,1 % des reboots "sauvages". Et 0,1 %, je suis gentil, ça doit être beaucoup moins.
Si on te paye pour ça, si on te paye pour être préoccupé par ça au lieu de t'investir dans d'autres domaines qui impactent significativement le fonctionnement de l'entreprise, alors t'es dans une boite blindée de tune et pas soucieuse du rendement, de la plus-value, de ses employés. Un conseil : restes y.
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 4.
> Qu'est ce que tu perds a utiliser ulimit? rien.
J'ai répondu à ça plus haut.
> mais j'ai l'impression que ce que t'as pas compris, c'est que, justement, le boulot de l'admin, ben c'est que ce genre de choses ca arrive pas.
Et ça t'est arrivé combien de fois sur des postes desktop ?
0 ou 1 fois ?
Et les conséquences ? Un reboot. Mais tu as vu combien de reboot "sauvage" (non désiré), de reset à cause d'un nouveau noyau qui a un driver qui sucks, ou à cause d'un problème hardware (une carte mal insérée, etc) ou de coupure de courant ? 1000 et peut-être probablement plus.
Si tu es préoccupé par les reboots "sauvage", je te comprend. Mais il y bien autres chose a faire avant de regarder du côté d'ulimit. Et tu configures ulimit pour que les fork bomb soient anodins, tu seras emmerdé par quelques utilisateurs qui font une utilisation un poil poussé de linux. Ils vont perdre du temps, tu vas perdre du temps pour finalement virer ou du moins atténué ulimit (ce qui probablement ne te mettra plus à l'apris d'un fork bomb). Et ça pour quoi ? Pour éviter au mieux 0,1 % des reboots "sauvages". Et 0,1 %, je suis gentil, ça doit être beaucoup moins.
Si on te paye pour ça, si on te paye pour être préoccupé par ça au lieu de t'investir dans d'autres domaines qui impactent significativement le fonctionnement de l'entreprise, alors t'es dans une boite blindée de tune et pas soucieuse du rendement, de la plus-value, de ses employés. Un conseil : restes y.