Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs processus à tasks.
Please explain that.
Je me demandais si on pouvait affecter des processus à un cgroup en les ajoutant au fichier virtuel tasks, et j'ai vu que c'était possible. Il me reste encore à essayer.
Puisque tu sembles regarder ça de près, dans des conditions réelles de grosse charge, pourrais tu mettre en ligne le résultat de tes expérimentation, s'te plait ?
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 11/19/2010 04:51 PM, Stéphan Peccini wrote:
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs
processus à tasks.
Please explain that.
Je me demandais si on pouvait affecter des processus à un cgroup en les
ajoutant au fichier virtuel tasks, et j'ai vu que c'était possible. Il me
reste encore à essayer.
Puisque tu sembles regarder ça de près, dans des conditions
réelles de grosse charge, pourrais tu mettre en ligne le
résultat de tes expérimentation, s'te plait ?
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Sinon, j'ai ma réponse ; on peut affecter bien évidemment plusieurs processus à tasks.
Please explain that.
Je me demandais si on pouvait affecter des processus à un cgroup en les ajoutant au fichier virtuel tasks, et j'ai vu que c'était possible. Il me reste encore à essayer.
Puisque tu sembles regarder ça de près, dans des conditions réelles de grosse charge, pourrais tu mettre en ligne le résultat de tes expérimentation, s'te plait ?
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Tonton Th
On 11/21/2010 10:55 AM, pehache-youplaboum wrote:
Quel que soit le gestionnaire de bureau, je trouve insupportables ces applications qui ouvrent des fenêtres par brassées entières.
s/bureau/fenêtres/
merci d'être rigoureux.
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 11/21/2010 10:55 AM, pehache-youplaboum wrote:
Quel que soit le gestionnaire de bureau, je trouve insupportables ces
applications qui ouvrent des fenêtres par brassées entières.
s/bureau/fenêtres/
merci d'être rigoureux.
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Sûrement écrit comme un pied, mais au moins ça marchait, je suis d'accord.
Mais il m'arrive régulièrement de vouloir faire pour un lot de photos (par exemple une pellicule de 8) un même traitement et le faire rapidement. J'en suis finalement arrivé à utiliser GraphicsMagick pour une partie car facile à scripter et faire une autre partie à la main et sous un autre produit que Gimp pour prendre en compte les 16 bits que me délivrent mon scanner. En fait je n'utilise Gimp que pour des images jpeg en entrée et ne nécessitant pas de traitement par lot.
On parle déjà entre du 8 bits et du 16 bits. Donc l'écart est plus important.
Mais franchement, quand je vois les solutions mises en oeuvre par cinepaint qui permet de traiter des images jusqu'en 32 bits et qui est utilisé au niveau professionel, bien évidemment sous la même licence que Gimp, je me dis que cela aurait pu être une bonne occasion d'y passer, voire temporairement en attendant le « depuis très^Wtrop longtemps attendu » GEGL complètement intégré dans Gimp.
Là, par contre, il est clair que peu de photographes sont restés ou venus à Gimp alors que si le 16 bits avaient été présent ainsi que les macros ou d'autres fonctionnalités fortement demandées, Gimp aurait été encore plus crédible. Mais bon, il y a eu un premier travail sur l'interface afin d'être assez conforme (celui-là je veux bien l'admettre, quoi que ...) et on annonçait le 16 bits. Et puis ... rien, toujours rien.
Ce qui est le plus important finalement (enfin pas pour moi), c'est d'avoir une interface qui soit conforme aux besoins du plus grand nombre et notamment des utilisateurs de Windows, quitte à retarder les éléments essentiels qui feraient venir de toute manière ceux qui sont intéressés et qui ne viennent pas à cause des manques. Ces utilisateurs, qui eux faisant des efforts, feraient des retours et feraient progresser Gimp globalement.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Michel Talon wrote:
Ca peut se programmer en Scheme gimp, non? A priori c'est un langage
autrement plus puissnat que n'importe quelle bouse à la Microsoft.
J'ai déjà fait ça et j'en avais fait un petit tutoriel :
Sûrement écrit comme un pied, mais au moins ça marchait, je suis d'accord.
Mais il m'arrive régulièrement de vouloir faire pour un lot de photos (par
exemple une pellicule de 8) un même traitement et le faire rapidement. J'en
suis finalement arrivé à utiliser GraphicsMagick pour une partie car facile
à scripter et faire une autre partie à la main et sous un autre produit que
Gimp pour prendre en compte les 16 bits que me délivrent mon scanner. En
fait je n'utilise Gimp que pour des images jpeg en entrée et ne nécessitant
pas de traitement par lot.
On parle déjà entre du 8 bits et du 16 bits. Donc l'écart est plus
important.
Mais franchement, quand je vois les solutions mises en oeuvre par cinepaint
qui permet de traiter des images jusqu'en 32 bits et qui est utilisé au
niveau professionel, bien évidemment sous la même licence que Gimp, je me
dis que cela aurait pu être une bonne occasion d'y passer, voire
temporairement en attendant le « depuis très^Wtrop longtemps attendu » GEGL
complètement intégré dans Gimp.
Là, par contre, il est clair que peu de photographes sont restés ou venus à
Gimp alors que si le 16 bits avaient été présent ainsi que les macros ou
d'autres fonctionnalités fortement demandées, Gimp aurait été encore plus
crédible. Mais bon, il y a eu un premier travail sur l'interface afin d'être
assez conforme (celui-là je veux bien l'admettre, quoi que ...) et on
annonçait le 16 bits. Et puis ... rien, toujours rien.
Ce qui est le plus important finalement (enfin pas pour moi), c'est d'avoir
une interface qui soit conforme aux besoins du plus grand nombre et
notamment des utilisateurs de Windows, quitte à retarder les éléments
essentiels qui feraient venir de toute manière ceux qui sont intéressés et
qui ne viennent pas à cause des manques. Ces utilisateurs, qui eux faisant
des efforts, feraient des retours et feraient progresser Gimp globalement.
--
Stéphan Peccini
Le blog : <URL:http://pyrenees.peccini.fr>
Les photos : <URL:http://photonature.fr>
Sûrement écrit comme un pied, mais au moins ça marchait, je suis d'accord.
Mais il m'arrive régulièrement de vouloir faire pour un lot de photos (par exemple une pellicule de 8) un même traitement et le faire rapidement. J'en suis finalement arrivé à utiliser GraphicsMagick pour une partie car facile à scripter et faire une autre partie à la main et sous un autre produit que Gimp pour prendre en compte les 16 bits que me délivrent mon scanner. En fait je n'utilise Gimp que pour des images jpeg en entrée et ne nécessitant pas de traitement par lot.
On parle déjà entre du 8 bits et du 16 bits. Donc l'écart est plus important.
Mais franchement, quand je vois les solutions mises en oeuvre par cinepaint qui permet de traiter des images jusqu'en 32 bits et qui est utilisé au niveau professionel, bien évidemment sous la même licence que Gimp, je me dis que cela aurait pu être une bonne occasion d'y passer, voire temporairement en attendant le « depuis très^Wtrop longtemps attendu » GEGL complètement intégré dans Gimp.
Là, par contre, il est clair que peu de photographes sont restés ou venus à Gimp alors que si le 16 bits avaient été présent ainsi que les macros ou d'autres fonctionnalités fortement demandées, Gimp aurait été encore plus crédible. Mais bon, il y a eu un premier travail sur l'interface afin d'être assez conforme (celui-là je veux bien l'admettre, quoi que ...) et on annonçait le 16 bits. Et puis ... rien, toujours rien.
Ce qui est le plus important finalement (enfin pas pour moi), c'est d'avoir une interface qui soit conforme aux besoins du plus grand nombre et notamment des utilisateurs de Windows, quitte à retarder les éléments essentiels qui feraient venir de toute manière ceux qui sont intéressés et qui ne viennent pas à cause des manques. Ces utilisateurs, qui eux faisant des efforts, feraient des retours et feraient progresser Gimp globalement.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Stéphan Peccini
Tonton Th wrote:
Bah toutes ces fenêtres de paramètres, tu les glisses dans le dock sous la boite à icones, et ça ira beaucoup mieux d'un coup...
Il l'a fait. Et il n'a plus que *2* fenêtres avec Gimp, chose que tout le monde peut faire avec, ce qui fait tomber l'argument (de ceux qui ne savent pas) des multiples fenêtres comme étant un défaut de Gimp.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Tonton Th wrote:
Bah toutes ces fenêtres de paramètres, tu les glisses dans
le dock sous la boite à icones, et ça ira beaucoup mieux
d'un coup...
Il l'a fait. Et il n'a plus que *2* fenêtres avec Gimp, chose que tout le
monde peut faire avec, ce qui fait tomber l'argument (de ceux qui ne savent
pas) des multiples fenêtres comme étant un défaut de Gimp.
--
Stéphan Peccini
Le blog : <URL:http://pyrenees.peccini.fr>
Les photos : <URL:http://photonature.fr>
Bah toutes ces fenêtres de paramètres, tu les glisses dans le dock sous la boite à icones, et ça ira beaucoup mieux d'un coup...
Il l'a fait. Et il n'a plus que *2* fenêtres avec Gimp, chose que tout le monde peut faire avec, ce qui fait tomber l'argument (de ceux qui ne savent pas) des multiples fenêtres comme étant un défaut de Gimp.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Stéphan Peccini
Tonton Th wrote:
Puisque tu sembles regarder ça de près, dans des conditions réelles de grosse charge, pourrais tu mettre en ligne le résultat de tes expérimentation, s'te plait ?
En fait le résultat, je l'ai déjà en partie montré : on peut lancer une fork bomb, avec une compilation de noyau en -j 64 et 60 copie de fichiers de 660 Mo en // sans faire bouger d'un iota la réactivité de la machine.
Ensuite, j'ai mis en place systemd qui fait la mise en oeuvre des cgroups pour le système et qui accessoirement accélère grandement le démarrage du système ; il sépare aussi chacun des utilisateurs dans un cgroup.
Je me suis mis en place un cgroup par tty dans le .bashrc pour pouvoir lancer mes commandes de batch en // et j'ai isolé les applications par type pour conserver la réactivité de l'environnement de bureaux et/ou de toutes les autres types d'applications (juste au cas où, hein ; c'est plus pour essayer que pour un réel besoin). Édition de /etc/cgrules.conf pour mettre des choses du type : stephan:gnumeric cpu user/stephan/applications/bureautique puis remplacement du raccourci vers gnumeric par cgexec gnumeric ; cela ne marche que sous Fedora ou assimilée mais le principe de cgexec est simple : il ne fait que récupérer le pid de la commande lancée et de le mettre dans le tasks du cgroup défini dans cgrules.conf.
Voilà. Pour l'instant, cela ne semble pas perturber le système et je peux me dire que je suis protégé contre ces fameuses fork bombs, ce qui est le cadet de mes soucis en dehors de fcold, mais surtout de ne plus me poser de question pour le lancement de mes batchs et d'une montée en charge trop forte et pénalisante du système.
Il faut maintenant que je regarde la partie blkio pour voir si on peut améliorer aussi la répartition des IOs entre les différentes applications. A priori, c'est faisable.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
Tonton Th wrote:
Puisque tu sembles regarder ça de près, dans des conditions
réelles de grosse charge, pourrais tu mettre en ligne le
résultat de tes expérimentation, s'te plait ?
En fait le résultat, je l'ai déjà en partie montré : on peut lancer une fork
bomb, avec une compilation de noyau en -j 64 et 60 copie de fichiers de 660
Mo en // sans faire bouger d'un iota la réactivité de la machine.
Ensuite, j'ai mis en place systemd qui fait la mise en oeuvre des cgroups
pour le système et qui accessoirement accélère grandement le démarrage du
système ; il sépare aussi chacun des utilisateurs dans un cgroup.
Je me suis mis en place un cgroup par tty dans le .bashrc pour pouvoir
lancer mes commandes de batch en // et j'ai isolé les applications par type
pour conserver la réactivité de l'environnement de bureaux et/ou de toutes
les autres types d'applications (juste au cas où, hein ; c'est plus pour
essayer que pour un réel besoin). Édition de /etc/cgrules.conf pour mettre
des choses du type :
stephan:gnumeric cpu user/stephan/applications/bureautique
puis remplacement du raccourci vers gnumeric par cgexec gnumeric ; cela ne
marche que sous Fedora ou assimilée mais le principe de cgexec est simple :
il ne fait que récupérer le pid de la commande lancée et de le mettre dans
le tasks du cgroup défini dans cgrules.conf.
Voilà. Pour l'instant, cela ne semble pas perturber le système et je peux me
dire que je suis protégé contre ces fameuses fork bombs, ce qui est le cadet
de mes soucis en dehors de fcold, mais surtout de ne plus me poser de
question pour le lancement de mes batchs et d'une montée en charge trop
forte et pénalisante du système.
Il faut maintenant que je regarde la partie blkio pour voir si on peut
améliorer aussi la répartition des IOs entre les différentes applications. A
priori, c'est faisable.
--
Stéphan Peccini
Le blog : <URL:http://pyrenees.peccini.fr>
Les photos : <URL:http://photonature.fr>
Puisque tu sembles regarder ça de près, dans des conditions réelles de grosse charge, pourrais tu mettre en ligne le résultat de tes expérimentation, s'te plait ?
En fait le résultat, je l'ai déjà en partie montré : on peut lancer une fork bomb, avec une compilation de noyau en -j 64 et 60 copie de fichiers de 660 Mo en // sans faire bouger d'un iota la réactivité de la machine.
Ensuite, j'ai mis en place systemd qui fait la mise en oeuvre des cgroups pour le système et qui accessoirement accélère grandement le démarrage du système ; il sépare aussi chacun des utilisateurs dans un cgroup.
Je me suis mis en place un cgroup par tty dans le .bashrc pour pouvoir lancer mes commandes de batch en // et j'ai isolé les applications par type pour conserver la réactivité de l'environnement de bureaux et/ou de toutes les autres types d'applications (juste au cas où, hein ; c'est plus pour essayer que pour un réel besoin). Édition de /etc/cgrules.conf pour mettre des choses du type : stephan:gnumeric cpu user/stephan/applications/bureautique puis remplacement du raccourci vers gnumeric par cgexec gnumeric ; cela ne marche que sous Fedora ou assimilée mais le principe de cgexec est simple : il ne fait que récupérer le pid de la commande lancée et de le mettre dans le tasks du cgroup défini dans cgrules.conf.
Voilà. Pour l'instant, cela ne semble pas perturber le système et je peux me dire que je suis protégé contre ces fameuses fork bombs, ce qui est le cadet de mes soucis en dehors de fcold, mais surtout de ne plus me poser de question pour le lancement de mes batchs et d'une montée en charge trop forte et pénalisante du système.
Il faut maintenant que je regarde la partie blkio pour voir si on peut améliorer aussi la répartition des IOs entre les différentes applications. A priori, c'est faisable.
-- Stéphan Peccini Le blog : <URL:http://pyrenees.peccini.fr> Les photos : <URL:http://photonature.fr>
pehache-youplaboum
On 22 nov, 06:30, Tonton Th wrote:
On 11/21/2010 10:55 AM, pehache-youplaboum wrote:
> Quel que soit le gestionnaire de bureau, je trouve insupportables ces > applications qui ouvrent des fenêtres par brassées entières.
s/bureau/fenêtres/
merci d'être rigoureux.
Il est vrai que "gestionnaire de bureau" ne se dit généralement pas et qu'on utilise plutôt "environnement de bureau" ou "bureau" tout court, pour autant ce n'est pas "gestionnaire de fenêtres" que j'ai voulu dire.
-- pehache
On 22 nov, 06:30, Tonton Th <t...@la.bas.invalid> wrote:
On 11/21/2010 10:55 AM, pehache-youplaboum wrote:
> Quel que soit le gestionnaire de bureau, je trouve insupportables ces
> applications qui ouvrent des fenêtres par brassées entières.
s/bureau/fenêtres/
merci d'être rigoureux.
Il est vrai que "gestionnaire de bureau" ne se dit généralement pas et
qu'on utilise plutôt "environnement de bureau" ou "bureau" tout court,
pour autant ce n'est pas "gestionnaire de fenêtres" que j'ai voulu
dire.
> Quel que soit le gestionnaire de bureau, je trouve insupportables ces > applications qui ouvrent des fenêtres par brassées entières.
s/bureau/fenêtres/
merci d'être rigoureux.
Il est vrai que "gestionnaire de bureau" ne se dit généralement pas et qu'on utilise plutôt "environnement de bureau" ou "bureau" tout court, pour autant ce n'est pas "gestionnaire de fenêtres" que j'ai voulu dire.
-- pehache
Doug713705
Le 22/11/2010 06:44 dans fr.comp.os.linux.debats Tonton Th nous expliquait:
Bah toutes ces fenêtres de paramètres, tu les glisses dans le dock sous la boite à icone
Le 22/11/2010 00:47 dans fr.comp.os.linux.debats ST nous expliquait:
"la securite des Unix est plutot ... rudimentaire et n'a strictement aucune lecon a donner a celle d'un serveur Windows (qui est d'ailleurs conceptuellement meilleure, si elle n'est pas plus efficace dans les faits)."
Oui, "... si elle n'est pas plus efficace dans les faits"
Justement c'est ce "si" qui est ambigüe. Comme écrit ici je le comprends comme "En terme de sécurité et de par sa conception, Windows est plus efficace qu'Unix. Les faits l'attestent."
Peut être voulais tu dire : "La sécurité des Unix est plutôt rudimentaire et n'a strictement aucune leçon à donner à celle d'un serveur Windows (qui est d'ailleurs conceptuellement meilleure _même_ si elle n'est pas plus efficace dans les faits)."
Ce qui reporterait la faute aux admin systèmes Windows et n'aurait pas le même sens, j'en conviens.
Si une sécurité est meilleure qu'une autre comment l'autre pourrait-elle ne pas être considérer moins fiable (à compétences et fréquences de mise à jour comparable) ?
Parce que la conception et l'implantation sont deux choses differentes.
Ah ben oui, sur papier glacé Windows est le meilleur OS du monde par contre sur un disque dur ce n'est plus pareil. -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ? Pour en savoir plus : http://usenet-fr.dougwise.org/
Le 22/11/2010 00:47 dans fr.comp.os.linux.debats ST nous expliquait:
"la securite des Unix est plutot ... rudimentaire et
n'a strictement aucune lecon a donner a celle d'un serveur Windows (qui
est d'ailleurs conceptuellement meilleure, si elle n'est pas plus
efficace dans les faits)."
Oui, "... si elle n'est pas plus efficace dans les faits"
Justement c'est ce "si" qui est ambigüe.
Comme écrit ici je le comprends comme "En terme de sécurité et de
par sa conception, Windows est plus efficace qu'Unix. Les faits
l'attestent."
Peut être voulais tu dire :
"La sécurité des Unix est plutôt rudimentaire et n'a strictement aucune
leçon à donner à celle d'un serveur Windows (qui est d'ailleurs
conceptuellement meilleure _même_ si elle n'est pas plus efficace dans
les faits)."
Ce qui reporterait la faute aux admin systèmes Windows et n'aurait pas
le même sens, j'en conviens.
Si une sécurité est meilleure qu'une autre comment l'autre
pourrait-elle ne pas être considérer moins fiable (à compétences et
fréquences de mise à jour comparable) ?
Parce que la conception et l'implantation sont deux choses differentes.
Ah ben oui, sur papier glacé Windows est le meilleur OS du monde par
contre sur un disque dur ce n'est plus pareil.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ?
Pour en savoir plus : http://usenet-fr.dougwise.org/
Le 22/11/2010 00:47 dans fr.comp.os.linux.debats ST nous expliquait:
"la securite des Unix est plutot ... rudimentaire et n'a strictement aucune lecon a donner a celle d'un serveur Windows (qui est d'ailleurs conceptuellement meilleure, si elle n'est pas plus efficace dans les faits)."
Oui, "... si elle n'est pas plus efficace dans les faits"
Justement c'est ce "si" qui est ambigüe. Comme écrit ici je le comprends comme "En terme de sécurité et de par sa conception, Windows est plus efficace qu'Unix. Les faits l'attestent."
Peut être voulais tu dire : "La sécurité des Unix est plutôt rudimentaire et n'a strictement aucune leçon à donner à celle d'un serveur Windows (qui est d'ailleurs conceptuellement meilleure _même_ si elle n'est pas plus efficace dans les faits)."
Ce qui reporterait la faute aux admin systèmes Windows et n'aurait pas le même sens, j'en conviens.
Si une sécurité est meilleure qu'une autre comment l'autre pourrait-elle ne pas être considérer moins fiable (à compétences et fréquences de mise à jour comparable) ?
Parce que la conception et l'implantation sont deux choses differentes.
Ah ben oui, sur papier glacé Windows est le meilleur OS du monde par contre sur un disque dur ce n'est plus pareil. -- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) Usenet-fr ? Mais qu'est-ce que c'est ? Comment ça marche ? Pour en savoir plus : http://usenet-fr.dougwise.org/
Nicolas George
Doug713705 , dans le message <icdcv9$4p8$, a écrit :
Ce qui reporterait la faute aux admin systèmes Windows et n'aurait pas le même sens, j'en conviens.
Pas seulement, il y a aussi le problème que l'implémentation des concepts si jolis sur le papier est pleine de bugs.
Doug713705 , dans le message <icdcv9$4p8$1@talisker.lacave.net>, a
écrit :
Ce qui reporterait la faute aux admin systèmes Windows et n'aurait pas
le même sens, j'en conviens.
Pas seulement, il y a aussi le problème que l'implémentation des concepts si
jolis sur le papier est pleine de bugs.
