> Apparemment, le second degré de mon commentaire précédent n'était pas assez apparent.
Désolé.
> Pour moi, limiter le nombre de processus par défaut est au même titre que l'utilisation de la mémoire protégée, ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur/des performances brutes mais permettant une sécurité, une stabilité et un confort d'utilisation compensant plus que largement son coût.
Non. Limiter le nombre de processus n'est pas la même chose que la mémoire protégée. Ce n'est pas parceque tu as de la mémoire protégée que tu ne peut pas faire un "malloc(4Go)" qui fait swapper ta bécane comme un fou voire aboutis à des "kill ... Out of memory" par le noyau.
La mémoire protégée c'est pour avoir plusieurs processus à la fois, ça ne limite pas l'utilisateur dans ce qu'il peut faire.
Par contre ulimit, comme son nom l'indique, limit l'utilisateur dans ce qu'il peut faire.
> ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur
Je ne te suis absolument pas.
En quoi du multitâche préemtif est une mesure restrictive ?
En quoi ça limite la liberté de l'utilisateur ?
Franchement, je ne vois pas du tout.
Si tu veux bouffer 100% du cpu et laisser 0% au autre, tu peux utiliser chrt (faut être root, sinon tu peux aussi faire un "chmod +s" ; c'est vivement déconseillé).
Le multitache préemtif n'est pas pour limiter les utilisateurs, c'est là encore le contraire. C'est pour permettre à plusieurs personne/programme de bosser en même temps. Au-lui qu'un programme attende la fin du programme en cours, il a la liberté de s'exécuter tout de suite.
Si tu as windows 3.1, il ne peut y avoir qu'une personne/programme à la fois. Si tu as un système multitache, t'as plus de liberté et non moins. Si plusieurs personnent utilisent le même PC en même temps, les ressources du PC sont plus utilisées et non moins utilisées.
Bref, je ne te comprend absolument pas.
> Laisser le nombre de processus illimité est un DoS potentiel, et il n'y aucune raison valable de ne pas combler cette faille.
Mais là tu parles d'un serveur. Un programme qui n'est pas accessible de l'extérieur ne peut pas être attaqué.
Au début du thread il y avait :
- "En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse..."
C'est un dire pour des distributions qui ne sont pas orientées serveurs mais orientées desktop (ça ce discute).
Puis je le répète pour la millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK".
> Je suis sous Slack et je limite *volontairement* le nombre de processus pour mon compte utilisateur.
TU te limites comme bon te semble, j'en ai rien à foutre. Mais si c'est un autre qui le fait pour toi ? Ça te plait ?
Si un jour le programme bidule ne se lance pas car il utiliser 201 thread et qu'un autre a limité le nombre de thread par process à 200 pour soit disant ton bien, t'es content ?
> Y a des gens qui ont le même dédain que toi pour la limitation du nombre de processus
Je n'ai aucun dédain pour ulimit, etc. C'est un truc indispensable pour un serveur. Mais limiter ce que fait l'utilisateur avec le prétexte que c'est pour son bien alors qu'on est dans un contexte desktop est de la connerie. S'il a 4 Go de mémoire et veut tout utiliser, c'est ses oignons, je ne vois pas pourquoi on va le limiter, et si ça fait ramer sa bécane au point de la rendre inutilisable, ça n'emmerde que lui. Je suis persuadé qu'il ne recommencera pas et que pour ce type de problème il est ridicule, pour ne pas dire néfaste, de développer une solution.
> En effet, même si on est un brave utilisateur qui ne lance jamais de programme malveillant, on n'est jamais à l'abri d'un programme tout à fait légitime, codé par des gens respectable, mais qui comporte un bug vicieux.
Si tu crois qu'un jour ou pourra éviter les effets de bord des programmes codés avec le pied, tu te trompes lourdement.
> Si ça arrive, chez moi le programme se fera tuer froidement par le noyau, mais toi tu rebooteras ta machine.
Oui, et je ne relance plus ce programme. Si ma bécane sert aussi de serveur, alors j'utilise ulimit. S'il n'y a que moi, alors je n'utilise pas ulimit.
Puis là encore on est dans du hors sujet. Limite toi tant que tu veux, je m'en fous. Mais qu'on te limite, tu serais d'accord ?
[^] # Re: public
Posté par IsNotGood . En réponse au journal De la confiance relative dans son produit. Évalué à 3.
Désolé.
> Pour moi, limiter le nombre de processus par défaut est au même titre que l'utilisation de la mémoire protégée, ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur/des performances brutes mais permettant une sécurité, une stabilité et un confort d'utilisation compensant plus que largement son coût.
Non. Limiter le nombre de processus n'est pas la même chose que la mémoire protégée. Ce n'est pas parceque tu as de la mémoire protégée que tu ne peut pas faire un "malloc(4Go)" qui fait swapper ta bécane comme un fou voire aboutis à des "kill ... Out of memory" par le noyau.
La mémoire protégée c'est pour avoir plusieurs processus à la fois, ça ne limite pas l'utilisateur dans ce qu'il peut faire.
Par contre ulimit, comme son nom l'indique, limit l'utilisateur dans ce qu'il peut faire.
> ou du multitâche préemptif, une mesure restrictive prise au détriment de la liberté de l'utilisateur
Je ne te suis absolument pas.
En quoi du multitâche préemtif est une mesure restrictive ?
En quoi ça limite la liberté de l'utilisateur ?
Franchement, je ne vois pas du tout.
Si tu veux bouffer 100% du cpu et laisser 0% au autre, tu peux utiliser chrt (faut être root, sinon tu peux aussi faire un "chmod +s" ; c'est vivement déconseillé).
Le multitache préemtif n'est pas pour limiter les utilisateurs, c'est là encore le contraire. C'est pour permettre à plusieurs personne/programme de bosser en même temps. Au-lui qu'un programme attende la fin du programme en cours, il a la liberté de s'exécuter tout de suite.
Si tu as windows 3.1, il ne peut y avoir qu'une personne/programme à la fois. Si tu as un système multitache, t'as plus de liberté et non moins. Si plusieurs personnent utilisent le même PC en même temps, les ressources du PC sont plus utilisées et non moins utilisées.
Bref, je ne te comprend absolument pas.
> Laisser le nombre de processus illimité est un DoS potentiel, et il n'y aucune raison valable de ne pas combler cette faille.
Mais là tu parles d'un serveur. Un programme qui n'est pas accessible de l'extérieur ne peut pas être attaqué.
Au début du thread il y avait :
- "En gros, OUI au contrôle du fork sous ubuntu/mandriva/suse..."
C'est un dire pour des distributions qui ne sont pas orientées serveurs mais orientées desktop (ça ce discute).
Puis je le répète pour la millième fois : "Qu'un OS se protège (par exemple avec les droits des fichiers), OK, mille fois OK".
> Je suis sous Slack et je limite *volontairement* le nombre de processus pour mon compte utilisateur.
TU te limites comme bon te semble, j'en ai rien à foutre. Mais si c'est un autre qui le fait pour toi ? Ça te plait ?
Si un jour le programme bidule ne se lance pas car il utiliser 201 thread et qu'un autre a limité le nombre de thread par process à 200 pour soit disant ton bien, t'es content ?
> Y a des gens qui ont le même dédain que toi pour la limitation du nombre de processus
Je n'ai aucun dédain pour ulimit, etc. C'est un truc indispensable pour un serveur. Mais limiter ce que fait l'utilisateur avec le prétexte que c'est pour son bien alors qu'on est dans un contexte desktop est de la connerie. S'il a 4 Go de mémoire et veut tout utiliser, c'est ses oignons, je ne vois pas pourquoi on va le limiter, et si ça fait ramer sa bécane au point de la rendre inutilisable, ça n'emmerde que lui. Je suis persuadé qu'il ne recommencera pas et que pour ce type de problème il est ridicule, pour ne pas dire néfaste, de développer une solution.
> En effet, même si on est un brave utilisateur qui ne lance jamais de programme malveillant, on n'est jamais à l'abri d'un programme tout à fait légitime, codé par des gens respectable, mais qui comporte un bug vicieux.
Si tu crois qu'un jour ou pourra éviter les effets de bord des programmes codés avec le pied, tu te trompes lourdement.
> Si ça arrive, chez moi le programme se fera tuer froidement par le noyau, mais toi tu rebooteras ta machine.
Oui, et je ne relance plus ce programme. Si ma bécane sert aussi de serveur, alors j'utilise ulimit. S'il n'y a que moi, alors je n'utilise pas ulimit.
Puis là encore on est dans du hors sujet. Limite toi tant que tu veux, je m'en fous. Mais qu'on te limite, tu serais d'accord ?