Tu racontes vraiment que des conneries depuis le début.
> À 140 d'upload la bécane est inutilisation.
FAUX, même à 700 de charge, et plus encore, une machine peut être parfaitement utilisable.
D'ailleurs, les serveurs de kernel.org sont à 400 de charge et pourtant ils fonctionnent...
Tu peux tester toi même. tu te mets un ulimit à 1000.
Tu lances ":(){ :|:& };:" dans un shell, et si la commande ne se fait pas tuer de suite, elle plafonnera à 1000 process, ta charge montera à 800 sans problème, mais X et le reste de tes applis tourneront sans problème.
> Je peux faire un truc qui fait monter ton upload à 140 et que ton "fork bomb detector" laissera en paix.
Impossible.
Par définition, la charge (load average) se définit par le nombre de processus en attente d'utiliser le CPU. Donc le load ne peut pas dépasser le nombre de processus maximum autorisé par ulimit et surtout pas le nombre de processus de tout le système.
Ensuite, si on se place dans ton contexte de marchine desktop, tu es incohérent avec toi même. Pourquoi dire OUI à la protection mémoire et NON à ulimit. Pour les même raisons que tu invoques contre ulimit, la protection mémoire ne sert à rien. Si tu lance un programme qui fait planter les autres, ben t'es vraiment le roi des cons si tu persites a lancer le même programme...
Pourquoi dire OUI à la protection des fichiers. Si tu es trop con pour effacer tes fichiers, il n'y a aucune raison que le système de t'en empéche. Tu serais encore le roi des cons pour faire 2 fois la même erreur...
Enfin, tu dis "ulimit comme outil de sécurité c'est assez limité"
Oui, comme tout les outil de sécurité, et ce n'est pas avec une seule brique que l'on construit un mur.
[^] # Re: public
Posté par Christophe Merlet (site web personnel) . En réponse au journal De la confiance relative dans son produit. Évalué à 4.
> À 140 d'upload la bécane est inutilisation.
FAUX, même à 700 de charge, et plus encore, une machine peut être parfaitement utilisable.
D'ailleurs, les serveurs de kernel.org sont à 400 de charge et pourtant ils fonctionnent...
Tu peux tester toi même. tu te mets un ulimit à 1000.
Tu lances ":(){ :|:& };:" dans un shell, et si la commande ne se fait pas tuer de suite, elle plafonnera à 1000 process, ta charge montera à 800 sans problème, mais X et le reste de tes applis tourneront sans problème.
> Je peux faire un truc qui fait monter ton upload à 140 et que ton "fork bomb detector" laissera en paix.
Impossible.
Par définition, la charge (load average) se définit par le nombre de processus en attente d'utiliser le CPU. Donc le load ne peut pas dépasser le nombre de processus maximum autorisé par ulimit et surtout pas le nombre de processus de tout le système.
Ensuite, si on se place dans ton contexte de marchine desktop, tu es incohérent avec toi même. Pourquoi dire OUI à la protection mémoire et NON à ulimit. Pour les même raisons que tu invoques contre ulimit, la protection mémoire ne sert à rien. Si tu lance un programme qui fait planter les autres, ben t'es vraiment le roi des cons si tu persites a lancer le même programme...
Pourquoi dire OUI à la protection des fichiers. Si tu es trop con pour effacer tes fichiers, il n'y a aucune raison que le système de t'en empéche. Tu serais encore le roi des cons pour faire 2 fois la même erreur...
Enfin, tu dis "ulimit comme outil de sécurité c'est assez limité"
Oui, comme tout les outil de sécurité, et ce n'est pas avec une seule brique que l'on construit un mur.