Comment purger la ram sous tiger via le terminal ?
31 réponses
Jean-Luc Courtois
Salut à tous,
J'ai feuilleté dans une revue un article qui propose de purger la ram
que certaines applis ne restituent pas après leur fermeture. Il est
question d'utiliser la commande purge du terminal, j'ai donc ouvert le
terminal et tapé purge : ça ne le fait pas (commande non reconnue).
Vous l'avez deviné, je suis bac -3 en terminal, je ne l'utilise
normalement qu'avec des copié/collé d'articles finalisés ;-)
Comment puis-je procéder ?
Merci pour la méthode :-)
--
Pour me répondre, pas de code postal dans l'adèle.
Non, il n'y a pas de valeur de retour, le père sait juste lorsque son fils est mort par l'appel wait() (ou waitpid()).
Si si, il y a une valeur de retour, exemple avec un shell : $ bash -c 'exit 12' $ echo $? 12
Le process père est capable de recevoir la valeur passé à exit par le process fils. C'est d'ailleurs pour laisser le temps au père de récupérer cette valeur que le fils passe en état zombie et doive acquitter de la mort du fils. Sinon cet état ne servirait à rien du tout.
Regardez wait(2) et exit(3) pour plus d'infos là dessus.
Et tu diras ce que tu voudras sur la libération de la mémoire, le fait est que si le père ne fait pas un wait et qu'il n'acquitte pas la mort de son fils, la mémoire ne libérera rien du tout.
Si, la mémoire est libérée. Un process zombie ne consomme absolument rien en dehors d'une entrée dans la table des process, démonstration :
$ cat test.c #include <stdlib.h>
int main(char **argc, char **argv) { if (fork()) { sleep(1000); } exit(0); } & gcc test.c $ ./a.out& [1] 18887 $ ps auxw USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND [...] dust 18889 0,0 0,0 0 0 p3 Z 16:26 0:00,00 <defunct> [...] dust 18887 0,0 0,0 1456 508 p3 I 16:26 0:00,00 ./a.out [...]
La colonne RSS et VSZ indiquent clairement que le process consomme 0 mémoire. Alors que le processus père consomme bien plus de mémoire alors qu'il ne fait qu'un sleep...
L'exemple ci-dessus est avec un FreeBSD, avec un Mac (testé à l'instant, mais j'ai du mal à faire un c/c depuis le Mac vers la machine avec laquelle je poste), ça marche pareil, sauf que le process zombie ne s'appelle pas "<defunct>", mais "(a.out)".
Enfin, le "Systeme" ne signifie rien du tout dans ce contexte. Parle-t'on du kernel, de la libc, du process init ... tous font partie du systeme.
La seule réalité d'un système Unix est la présence d'un système quelque part. Le reste peut être totalement trompeur. En l'occurence ici, je parle du Kernel : c'est lui qui libère la mémoire à la mort du process.
Oui, si ce n'est qu'un process zombie a déjà libéré sa mémoire, et ne consomme quasi aucune ressource (en vrai, il ne consomme qu'une entrée dans la table des process, autant dire moins d'un ko de données).
Oui, c'est exact. Raison de plus pour pas vraiment s'en inquiéter.
Voilà.
ST <st@unices.org> écrit :
Non, il n'y a pas de valeur de retour, le père sait juste lorsque son
fils est mort par l'appel wait() (ou waitpid()).
Si si, il y a une valeur de retour, exemple avec un shell :
$ bash -c 'exit 12'
$ echo $?
12
Le process père est capable de recevoir la valeur passé à exit par le
process fils. C'est d'ailleurs pour laisser le temps au père de
récupérer cette valeur que le fils passe en état zombie et doive
acquitter de la mort du fils. Sinon cet état ne servirait à rien du
tout.
Regardez wait(2) et exit(3) pour plus d'infos là dessus.
Et tu diras ce que tu voudras sur la libération de la mémoire, le fait
est que si le père ne fait pas un wait et qu'il n'acquitte pas la mort
de son fils, la mémoire ne libérera rien du tout.
Si, la mémoire est libérée. Un process zombie ne consomme absolument
rien en dehors d'une entrée dans la table des process, démonstration :
$ cat test.c
#include <stdlib.h>
int main(char **argc, char **argv) {
if (fork()) {
sleep(1000);
}
exit(0);
}
& gcc test.c
$ ./a.out&
[1] 18887
$ ps auxw
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
[...]
dust 18889 0,0 0,0 0 0 p3 Z 16:26 0:00,00 <defunct>
[...]
dust 18887 0,0 0,0 1456 508 p3 I 16:26 0:00,00 ./a.out
[...]
La colonne RSS et VSZ indiquent clairement que le process consomme 0
mémoire. Alors que le processus père consomme bien plus de mémoire
alors qu'il ne fait qu'un sleep...
L'exemple ci-dessus est avec un FreeBSD, avec un Mac (testé à
l'instant, mais j'ai du mal à faire un c/c depuis le Mac vers la
machine avec laquelle je poste), ça marche pareil, sauf que le process
zombie ne s'appelle pas "<defunct>", mais "(a.out)".
Enfin, le "Systeme" ne signifie rien du tout dans ce contexte.
Parle-t'on du kernel, de la libc, du process init ... tous font partie
du systeme.
La seule réalité d'un système Unix est la présence d'un système
quelque part. Le reste peut être totalement trompeur. En l'occurence
ici, je parle du Kernel : c'est lui qui libère la mémoire à la mort du
process.
Oui, si ce n'est qu'un process zombie a déjà libéré sa mémoire, et ne
consomme quasi aucune ressource (en vrai, il ne consomme qu'une entrée
dans la table des process, autant dire moins d'un ko de données).
Oui, c'est exact. Raison de plus pour pas vraiment s'en inquiéter.
Non, il n'y a pas de valeur de retour, le père sait juste lorsque son fils est mort par l'appel wait() (ou waitpid()).
Si si, il y a une valeur de retour, exemple avec un shell : $ bash -c 'exit 12' $ echo $? 12
Le process père est capable de recevoir la valeur passé à exit par le process fils. C'est d'ailleurs pour laisser le temps au père de récupérer cette valeur que le fils passe en état zombie et doive acquitter de la mort du fils. Sinon cet état ne servirait à rien du tout.
Regardez wait(2) et exit(3) pour plus d'infos là dessus.
Et tu diras ce que tu voudras sur la libération de la mémoire, le fait est que si le père ne fait pas un wait et qu'il n'acquitte pas la mort de son fils, la mémoire ne libérera rien du tout.
Si, la mémoire est libérée. Un process zombie ne consomme absolument rien en dehors d'une entrée dans la table des process, démonstration :
$ cat test.c #include <stdlib.h>
int main(char **argc, char **argv) { if (fork()) { sleep(1000); } exit(0); } & gcc test.c $ ./a.out& [1] 18887 $ ps auxw USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND [...] dust 18889 0,0 0,0 0 0 p3 Z 16:26 0:00,00 <defunct> [...] dust 18887 0,0 0,0 1456 508 p3 I 16:26 0:00,00 ./a.out [...]
La colonne RSS et VSZ indiquent clairement que le process consomme 0 mémoire. Alors que le processus père consomme bien plus de mémoire alors qu'il ne fait qu'un sleep...
L'exemple ci-dessus est avec un FreeBSD, avec un Mac (testé à l'instant, mais j'ai du mal à faire un c/c depuis le Mac vers la machine avec laquelle je poste), ça marche pareil, sauf que le process zombie ne s'appelle pas "<defunct>", mais "(a.out)".
Enfin, le "Systeme" ne signifie rien du tout dans ce contexte. Parle-t'on du kernel, de la libc, du process init ... tous font partie du systeme.
La seule réalité d'un système Unix est la présence d'un système quelque part. Le reste peut être totalement trompeur. En l'occurence ici, je parle du Kernel : c'est lui qui libère la mémoire à la mort du process.
Oui, si ce n'est qu'un process zombie a déjà libéré sa mémoire, et ne consomme quasi aucune ressource (en vrai, il ne consomme qu'une entrée dans la table des process, autant dire moins d'un ko de données).
Oui, c'est exact. Raison de plus pour pas vraiment s'en inquiéter.
Voilà.
Jean-Luc Courtois
Le 29/08/11 09:13, Jean-Luc Courtois a écrit :
Merci à tous pour les bons plans ;-)
Le reboot évidemment, tirer sur la prise d'alimentation ça doit le faire aussi...
Le moniteur d'activités je sais m'en servir, et j'ai aussi l'excellent menu meters qui me renvoie le camembert d'occupation ram (entre autres) dans la barre des menus. C'est comme ça que je vois mon camembert plein, même si l'inactive est censée être "disponible" (merci Matt pour le rappel des liens utiles) j'ai l'impression, celle d'un utilisateur, que mon iMac G5 (2Go de ram, le max) rame un peu dans ces conditions. C'est souvent Safari qui stocke, le fait de le quitter et de le relancer redonne de l'oxygène.
Je n'ai pas à me plaindre du Tigre, la preuve, je le garde même avec un DVD universel de Léopard sur l'étagère ;-)
Dans la revue en question, il y avait le détail pour un script, je vais essayer, c'est surtout pour ma curiosité, plus que pour la chasse aux zombis 8/
-- Pour me répondre, pas de code postal dans l'adèle.
Le 29/08/11 09:13, Jean-Luc Courtois a écrit :
Merci à tous pour les bons plans ;-)
Le reboot évidemment, tirer sur la prise d'alimentation ça doit le faire
aussi...
Le moniteur d'activités je sais m'en servir, et j'ai aussi l'excellent
menu meters qui me renvoie le camembert d'occupation ram (entre autres)
dans la barre des menus. C'est comme ça que je vois mon camembert plein,
même si l'inactive est censée être "disponible" (merci Matt pour le
rappel des liens utiles) j'ai l'impression, celle d'un utilisateur, que
mon iMac G5 (2Go de ram, le max) rame un peu dans ces conditions. C'est
souvent Safari qui stocke, le fait de le quitter et de le relancer
redonne de l'oxygène.
Je n'ai pas à me plaindre du Tigre, la preuve, je le garde même avec un
DVD universel de Léopard sur l'étagère ;-)
Dans la revue en question, il y avait le détail pour un script, je vais
essayer, c'est surtout pour ma curiosité, plus que pour la chasse aux
zombis 8/
--
Pour me répondre, pas de code postal dans l'adèle.
Le reboot évidemment, tirer sur la prise d'alimentation ça doit le faire aussi...
Le moniteur d'activités je sais m'en servir, et j'ai aussi l'excellent menu meters qui me renvoie le camembert d'occupation ram (entre autres) dans la barre des menus. C'est comme ça que je vois mon camembert plein, même si l'inactive est censée être "disponible" (merci Matt pour le rappel des liens utiles) j'ai l'impression, celle d'un utilisateur, que mon iMac G5 (2Go de ram, le max) rame un peu dans ces conditions. C'est souvent Safari qui stocke, le fait de le quitter et de le relancer redonne de l'oxygène.
Je n'ai pas à me plaindre du Tigre, la preuve, je le garde même avec un DVD universel de Léopard sur l'étagère ;-)
Dans la revue en question, il y avait le détail pour un script, je vais essayer, c'est surtout pour ma curiosité, plus que pour la chasse aux zombis 8/
-- Pour me répondre, pas de code postal dans l'adèle.
ST
On 29/8/11 10:39 PM, Che Averell wrote:
Si si, il y a une valeur de retour, exemple avec un shell : $ bash -c 'exit 12' $ echo $? 12
Va donc lire le man de wait ou de waitpid au lieu de confondre developpement et script shell.
Si, la mémoire est libérée. Un process zombie ne consomme absolument rien en dehors d'une entrée dans la table des process, démonstration :
Oui, la mémoire est liberée, j'ai fais un abus de language. Mais le PID ne sortira pas de la table des process quand meme.
La seule réalité d'un système Unix est la présence d'un système quelque part. Le reste peut être totalement trompeur. En l'occurence ici, je parle du Kernel : c'est lui qui libère la mémoire à la mort du process.
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware et comme la mémoire est du hardware. Il est certain que quelques soient les triggers entres les deux, à un moment donné, ça va passer par le kernel.
T'aimes bien les lapalicades, j'ai remarqué.
-- http://www.unices.org
On 29/8/11 10:39 PM, Che Averell wrote:
Si si, il y a une valeur de retour, exemple avec un shell :
$ bash -c 'exit 12'
$ echo $?
12
Va donc lire le man de wait ou de waitpid au lieu de confondre
developpement et script shell.
Si, la mémoire est libérée. Un process zombie ne consomme absolument
rien en dehors d'une entrée dans la table des process, démonstration :
Oui, la mémoire est liberée, j'ai fais un abus de language. Mais le PID
ne sortira pas de la table des process quand meme.
La seule réalité d'un système Unix est la présence d'un système
quelque part. Le reste peut être totalement trompeur. En l'occurence
ici, je parle du Kernel : c'est lui qui libère la mémoire à la mort du
process.
Ben, comme le kernel est l'interface entre le monde du logiciel et le
monde du hardware et comme la mémoire est du hardware. Il est certain
que quelques soient les triggers entres les deux, à un moment donné, ça
va passer par le kernel.
Si si, il y a une valeur de retour, exemple avec un shell : $ bash -c 'exit 12' $ echo $? 12
Va donc lire le man de wait ou de waitpid au lieu de confondre developpement et script shell.
Si, la mémoire est libérée. Un process zombie ne consomme absolument rien en dehors d'une entrée dans la table des process, démonstration :
Oui, la mémoire est liberée, j'ai fais un abus de language. Mais le PID ne sortira pas de la table des process quand meme.
La seule réalité d'un système Unix est la présence d'un système quelque part. Le reste peut être totalement trompeur. En l'occurence ici, je parle du Kernel : c'est lui qui libère la mémoire à la mort du process.
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware et comme la mémoire est du hardware. Il est certain que quelques soient les triggers entres les deux, à un moment donné, ça va passer par le kernel.
T'aimes bien les lapalicades, j'ai remarqué.
-- http://www.unices.org
xavier
ST wrote:
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware
Raté, sur MacOSX, c'est le micronoyau Mach qui joue ce rôle.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
ST <st@unices.org> wrote:
Ben, comme le kernel est l'interface entre le monde du logiciel et le
monde du hardware
Raté, sur MacOSX, c'est le micronoyau Mach qui joue ce rôle.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware
Raté, sur MacOSX, c'est le micronoyau Mach qui joue ce rôle.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Che Averell
ST écrit :
Va donc lire le man de wait ou de waitpid au lieu de confondre developpement et script shell.
T'es gentil, mais la page man de wait, je la connais. Et si je te dis que le process fils envoi une valeur de statut à son père en mourrant, c'est que c'est vrai, et c'est d'ailleurs ce que je t'ai prouvé avec mon petit bout de script shell.
Mais si tu veux que je te le refasse en C, tient, cadeau : $ cat test.c #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h>
int main(char **argc, char **argv) { pid_t fils; int status; fils = fork(); if (fils) { // pere waitpid (fils, &status, 0); printf ("status du fils: %dn", WEXITSTATUS(status)); } else { // fils exit (42); } exit(0); } $ gcc test.c $ ./a.out status du fils: 42
On voit clairement que le père récupère via waitpid la valeur fournie par le fils à exit.
Au passage, tu serais gentil de changer un poil de ton et d'arrêter d'asséner des contre-vérités : il est clair que tu ne maitrîses pas le sujet. Reste humble, et accepte les remarques courtoises que l'on te fait.
Si, la mémoire est libérée. Un process zombie ne consomme absolument rien en dehors d'une entrée dans la table des process, démonstration :
Oui, la mémoire est liberée, j'ai fais un abus de language. Mais le PID ne sortira pas de la table des process quand meme.
Oui, c'est ce que je dit depuis mon premier message.
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware et comme la mémoire est du hardware. Il est certain que quelques soient les triggers entres les deux, à un moment donné, ça va passer par le kernel. T'aimes bien les lapalicades, j'ai remarqué.
Sauf que c'est pas vraiment ce que j'ai écrit. Tu soutiens que c'est au père de libérer la mémoire du fils, je te dit que non, c'est le kernel qui s'en charge. Nulle part je n'ai fait mention du matériel.
ST <st@unices.org> écrit :
Va donc lire le man de wait ou de waitpid au lieu de confondre
developpement et script shell.
T'es gentil, mais la page man de wait, je la connais. Et si je te dis
que le process fils envoi une valeur de statut à son père en mourrant,
c'est que c'est vrai, et c'est d'ailleurs ce que je t'ai prouvé avec
mon petit bout de script shell.
Mais si tu veux que je te le refasse en C, tient, cadeau :
$ cat test.c
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(char **argc, char **argv) {
pid_t fils;
int status;
fils = fork();
if (fils) {
// pere
waitpid (fils, &status, 0);
printf ("status du fils: %dn", WEXITSTATUS(status));
} else {
// fils
exit (42);
}
exit(0);
}
$ gcc test.c
$ ./a.out
status du fils: 42
On voit clairement que le père récupère via waitpid la valeur fournie
par le fils à exit.
Au passage, tu serais gentil de changer un poil de ton et d'arrêter
d'asséner des contre-vérités : il est clair que tu ne maitrîses pas le
sujet. Reste humble, et accepte les remarques courtoises que l'on te
fait.
Si, la mémoire est libérée. Un process zombie ne consomme absolument
rien en dehors d'une entrée dans la table des process, démonstration :
Oui, la mémoire est liberée, j'ai fais un abus de language. Mais le
PID ne sortira pas de la table des process quand meme.
Oui, c'est ce que je dit depuis mon premier message.
Ben, comme le kernel est l'interface entre le monde du logiciel et le
monde du hardware et comme la mémoire est du hardware. Il est certain
que quelques soient les triggers entres les deux, à un moment donné,
ça va passer par le kernel.
T'aimes bien les lapalicades, j'ai remarqué.
Sauf que c'est pas vraiment ce que j'ai écrit. Tu soutiens que c'est
au père de libérer la mémoire du fils, je te dit que non, c'est le
kernel qui s'en charge. Nulle part je n'ai fait mention du matériel.
Va donc lire le man de wait ou de waitpid au lieu de confondre developpement et script shell.
T'es gentil, mais la page man de wait, je la connais. Et si je te dis que le process fils envoi une valeur de statut à son père en mourrant, c'est que c'est vrai, et c'est d'ailleurs ce que je t'ai prouvé avec mon petit bout de script shell.
Mais si tu veux que je te le refasse en C, tient, cadeau : $ cat test.c #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h>
int main(char **argc, char **argv) { pid_t fils; int status; fils = fork(); if (fils) { // pere waitpid (fils, &status, 0); printf ("status du fils: %dn", WEXITSTATUS(status)); } else { // fils exit (42); } exit(0); } $ gcc test.c $ ./a.out status du fils: 42
On voit clairement que le père récupère via waitpid la valeur fournie par le fils à exit.
Au passage, tu serais gentil de changer un poil de ton et d'arrêter d'asséner des contre-vérités : il est clair que tu ne maitrîses pas le sujet. Reste humble, et accepte les remarques courtoises que l'on te fait.
Si, la mémoire est libérée. Un process zombie ne consomme absolument rien en dehors d'une entrée dans la table des process, démonstration :
Oui, la mémoire est liberée, j'ai fais un abus de language. Mais le PID ne sortira pas de la table des process quand meme.
Oui, c'est ce que je dit depuis mon premier message.
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware et comme la mémoire est du hardware. Il est certain que quelques soient les triggers entres les deux, à un moment donné, ça va passer par le kernel. T'aimes bien les lapalicades, j'ai remarqué.
Sauf que c'est pas vraiment ce que j'ai écrit. Tu soutiens que c'est au père de libérer la mémoire du fils, je te dit que non, c'est le kernel qui s'en charge. Nulle part je n'ai fait mention du matériel.
ST
On 30/8/11 12:37 AM, Xavier wrote:
ST wrote:
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware
Raté, sur MacOSX, c'est le micronoyau Mach qui joue ce rôle.
C'est en anglais que tu as un probleme ?
"noyau" se dit "kernel".
-- http://www.unices.org
On 30/8/11 12:37 AM, Xavier wrote:
ST<st@unices.org> wrote:
Ben, comme le kernel est l'interface entre le monde du logiciel et le
monde du hardware
Raté, sur MacOSX, c'est le micronoyau Mach qui joue ce rôle.
Ben, comme le kernel est l'interface entre le monde du logiciel et le monde du hardware
Raté, sur MacOSX, c'est le micronoyau Mach qui joue ce rôle.
C'est en anglais que tu as un probleme ?
"noyau" se dit "kernel".
-- http://www.unices.org
ST
On 30/8/11 12:38 AM, Che Averell wrote:
T'es gentil, mais la page man de wait, je la connais. Et si je te dis que le process fils envoi une valeur de statut à son père en mourrant,
Ah yep, au temps pour moi, c'est vrai qu'il y a un pointeur sur ca.
Au passage, tu serais gentil de changer un poil de ton et d'arrêter d'asséner des contre-vérités : il est clair que tu ne maitrîses pas le sujet. Reste humble, et accepte les remarques courtoises que l'on te fait.
Je prends le ton que je veux et si ca te plait pas ... je t'emmerde.
Sauf que c'est pas vraiment ce que j'ai écrit. Tu soutiens que c'est au père de libérer la mémoire du fils, je te dit que non, c'est le kernel qui s'en charge. Nulle part je n'ai fait mention du matériel.
Ouah, p'tain tu t'accroches. J'ai deja dit que j'avais fait un abus de language. Sur le fond, on est d'accord, ma connaissance est plus empirique que theorique et ta bite est plus grande.
P'tain, meme sur ce groupe faut qu'on se tappe un JKB ... fais chier.
De toutes facons, le point important est qu'il n'y a pas a se soucier de purger la memoire sur un Mac OS X et point final.
-- http://www.unices.org
On 30/8/11 12:38 AM, Che Averell wrote:
T'es gentil, mais la page man de wait, je la connais. Et si je te dis
que le process fils envoi une valeur de statut à son père en mourrant,
Ah yep, au temps pour moi, c'est vrai qu'il y a un pointeur sur ca.
Au passage, tu serais gentil de changer un poil de ton et d'arrêter
d'asséner des contre-vérités : il est clair que tu ne maitrîses pas le
sujet. Reste humble, et accepte les remarques courtoises que l'on te
fait.
Je prends le ton que je veux et si ca te plait pas ... je t'emmerde.
Sauf que c'est pas vraiment ce que j'ai écrit. Tu soutiens que c'est
au père de libérer la mémoire du fils, je te dit que non, c'est le
kernel qui s'en charge. Nulle part je n'ai fait mention du matériel.
Ouah, p'tain tu t'accroches. J'ai deja dit que j'avais fait un abus de
language. Sur le fond, on est d'accord, ma connaissance est plus
empirique que theorique et ta bite est plus grande.
P'tain, meme sur ce groupe faut qu'on se tappe un JKB ... fais chier.
De toutes facons, le point important est qu'il n'y a pas a se soucier de
purger la memoire sur un Mac OS X et point final.
T'es gentil, mais la page man de wait, je la connais. Et si je te dis que le process fils envoi une valeur de statut à son père en mourrant,
Ah yep, au temps pour moi, c'est vrai qu'il y a un pointeur sur ca.
Au passage, tu serais gentil de changer un poil de ton et d'arrêter d'asséner des contre-vérités : il est clair que tu ne maitrîses pas le sujet. Reste humble, et accepte les remarques courtoises que l'on te fait.
Je prends le ton que je veux et si ca te plait pas ... je t'emmerde.
Sauf que c'est pas vraiment ce que j'ai écrit. Tu soutiens que c'est au père de libérer la mémoire du fils, je te dit que non, c'est le kernel qui s'en charge. Nulle part je n'ai fait mention du matériel.
Ouah, p'tain tu t'accroches. J'ai deja dit que j'avais fait un abus de language. Sur le fond, on est d'accord, ma connaissance est plus empirique que theorique et ta bite est plus grande.
P'tain, meme sur ce groupe faut qu'on se tappe un JKB ... fais chier.
De toutes facons, le point important est qu'il n'y a pas a se soucier de purger la memoire sur un Mac OS X et point final.
-- http://www.unices.org
J.P
In article , ST wrote:
Je prends le ton que je veux et si ca te plait pas ... je t'emmerde.
Ce genre de vocabulaire serait-il courant chez les barbus administrateurs système en CLI, script etc. ?
-- Jean-Pierre
In article <rc1ui8-qa82.ln1@gulliver.unices.org>, ST <st@unices.org>
wrote:
Je prends le ton que je veux et si ca te plait pas ... je t'emmerde.
Ce genre de vocabulaire serait-il courant chez les barbus
administrateurs système en CLI, script etc. ?
