j'ai un Mac PRO osus OS X Server pour jouer avec quelques temps, et j'ai
un gros soucis.
Le but du jeu actuel, c'est de capturer le traffic réseau sur sa seconde
interface réseau "en1" :
oui, mais je crois qu'apple fait quand même de plus en plus d'effort.
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant, as-tu regardé du côté des packages proposés par MySQL, ils s'installent très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on évite les migraines dans les MAJ Apple).
d'ailleurs, étrangement, le macpro donne de meilleurs résultats avec la config mysql out-of-the-box qu'avec une config optimisée.
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te fournir je pense, est largement mieux optimisé, résultat de sa compilation avec GCC 4 au lieu de 3.3 ?
Côté Sun, j'ai beau faire n'importe quoi avec la config, j'obtiens toujours les mêmes bons résultats :D
C't'agaçant hein ?
à suivre, je viens de rebooter le macpro, et je vais lui remettre une tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
oui, mais je crois qu'apple fait quand même de plus en plus d'effort.
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant,
as-tu regardé du côté des packages proposés par MySQL, ils s'installent
très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on
évite les migraines dans les MAJ Apple).
d'ailleurs, étrangement, le macpro donne de meilleurs résultats avec la
config mysql out-of-the-box qu'avec une config optimisée.
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te
fournir je pense, est largement mieux optimisé, résultat de sa
compilation avec GCC 4 au lieu de 3.3 ?
Côté Sun, j'ai
beau faire n'importe quoi avec la config, j'obtiens toujours les mêmes
bons résultats :D
C't'agaçant hein ?
à suivre, je viens de rebooter le macpro, et je vais lui remettre une
tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
oui, mais je crois qu'apple fait quand même de plus en plus d'effort.
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant, as-tu regardé du côté des packages proposés par MySQL, ils s'installent très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on évite les migraines dans les MAJ Apple).
d'ailleurs, étrangement, le macpro donne de meilleurs résultats avec la config mysql out-of-the-box qu'avec une config optimisée.
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te fournir je pense, est largement mieux optimisé, résultat de sa compilation avec GCC 4 au lieu de 3.3 ?
Côté Sun, j'ai beau faire n'importe quoi avec la config, j'obtiens toujours les mêmes bons résultats :D
C't'agaçant hein ?
à suivre, je viens de rebooter le macpro, et je vais lui remettre une tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski
In article <1hng9y8.54y046xqc52cN%, (Laurent Pertois) wrote:
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant, as-tu regardé du côté des packages proposés par MySQL, ils s'installent très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on évite les migraines dans les MAJ Apple).
voui, mais bon, il y'a déjà tellement de choses a tester, de combinaisons de paramètres que je vais essayer de pas me disperser en multipliant les versions de MySQL ;)
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te fournir je pense, est largement mieux optimisé, résultat de sa compilation avec GCC 4 au lieu de 3.3 ?
ça tourne pas mal oui, mais le multithread est toujours un peu à la ramasse... D'ailleurs la direction qu'Intel et AMD prennent et qui consiste à tenter d'agréger plusieurs cores pour "simuler" un processeur unique plus rapide est, à mon sens, un gros désaveux pour les développeurs (en plus d'être un workaround au coup de frein sur les fréquences brutes)
Côté Sun, j'ai beau faire n'importe quoi avec la config, j'obtiens toujours les mêmes bons résultats :D
C't'agaçant hein ?
oui, je me dis que je dois rater un truc énorme et que je devrais pouvoir la pousser encore plus.
à suivre, je viens de rebooter le macpro, et je vais lui remettre une tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
il s'est revautré, pas grave, mais pas sans conséquences. J'avais réduit le backlog de mysqld à une valeur assez faible, ainsi que le nombre de thread max : peu de thread concurrents et impossibilité d'en mettre beaucoup en attente. Donc en théorie, un processeur rapide doit s'en sortir correctement par rapport à un processeur "lent", qui aurait du subir des tas de "too many connections". En réalité, encore une fois la sun s'en sort impeccablement, et le macpro se viande dans les grandes largeurs, et c'est lui qui a reçu des erreurs.
Juste pour faire patienter avant que je fasse d'autres benches voilà un aperçu des résultats actuels :
In article <1hng9y8.54y046xqc52cN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant,
as-tu regardé du côté des packages proposés par MySQL, ils s'installent
très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on
évite les migraines dans les MAJ Apple).
voui, mais bon, il y'a déjà tellement de choses a tester, de
combinaisons de paramètres que je vais essayer de pas me disperser en
multipliant les versions de MySQL ;)
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te
fournir je pense, est largement mieux optimisé, résultat de sa
compilation avec GCC 4 au lieu de 3.3 ?
ça tourne pas mal oui, mais le multithread est toujours un peu à la
ramasse... D'ailleurs la direction qu'Intel et AMD prennent et qui
consiste à tenter d'agréger plusieurs cores pour "simuler" un processeur
unique plus rapide est, à mon sens, un gros désaveux pour les
développeurs (en plus d'être un workaround au coup de frein sur les
fréquences brutes)
Côté Sun, j'ai
beau faire n'importe quoi avec la config, j'obtiens toujours les mêmes
bons résultats :D
C't'agaçant hein ?
oui, je me dis que je dois rater un truc énorme et que je devrais
pouvoir la pousser encore plus.
à suivre, je viens de rebooter le macpro, et je vais lui remettre une
tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
il s'est revautré, pas grave, mais pas sans conséquences.
J'avais réduit le backlog de mysqld à une valeur assez faible, ainsi que
le nombre de thread max : peu de thread concurrents et impossibilité
d'en mettre beaucoup en attente. Donc en théorie, un processeur rapide
doit s'en sortir correctement par rapport à un processeur "lent", qui
aurait du subir des tas de "too many connections".
En réalité, encore une fois la sun s'en sort impeccablement, et le
macpro se viande dans les grandes largeurs, et c'est lui qui a reçu des
erreurs.
Juste pour faire patienter avant que je fasse d'autres benches voilà un
aperçu des résultats actuels :
In article <1hng9y8.54y046xqc52cN%, (Laurent Pertois) wrote:
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant, as-tu regardé du côté des packages proposés par MySQL, ils s'installent très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on évite les migraines dans les MAJ Apple).
voui, mais bon, il y'a déjà tellement de choses a tester, de combinaisons de paramètres que je vais essayer de pas me disperser en multipliant les versions de MySQL ;)
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te fournir je pense, est largement mieux optimisé, résultat de sa compilation avec GCC 4 au lieu de 3.3 ?
ça tourne pas mal oui, mais le multithread est toujours un peu à la ramasse... D'ailleurs la direction qu'Intel et AMD prennent et qui consiste à tenter d'agréger plusieurs cores pour "simuler" un processeur unique plus rapide est, à mon sens, un gros désaveux pour les développeurs (en plus d'être un workaround au coup de frein sur les fréquences brutes)
Côté Sun, j'ai beau faire n'importe quoi avec la config, j'obtiens toujours les mêmes bons résultats :D
C't'agaçant hein ?
oui, je me dis que je dois rater un truc énorme et que je devrais pouvoir la pousser encore plus.
à suivre, je viens de rebooter le macpro, et je vais lui remettre une tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
il s'est revautré, pas grave, mais pas sans conséquences. J'avais réduit le backlog de mysqld à une valeur assez faible, ainsi que le nombre de thread max : peu de thread concurrents et impossibilité d'en mettre beaucoup en attente. Donc en théorie, un processeur rapide doit s'en sortir correctement par rapport à un processeur "lent", qui aurait du subir des tas de "too many connections". En réalité, encore une fois la sun s'en sort impeccablement, et le macpro se viande dans les grandes largeurs, et c'est lui qui a reçu des erreurs.
Juste pour faire patienter avant que je fasse d'autres benches voilà un aperçu des résultats actuels :
In article <1hng9y8.54y046xqc52cN%, (Laurent Pertois) wrote:
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant, as-tu regardé du côté des packages proposés par MySQL, ils s'installent très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on évite les migraines dans les MAJ Apple).
voui, mais bon, il y'a déjà tellement de choses a tester, de combinaisons de paramètres que je vais essayer de pas me disperser en multipliant les versions de MySQL ;)
Certes, je te comprends.
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te fournir je pense, est largement mieux optimisé, résultat de sa compilation avec GCC 4 au lieu de 3.3 ?
ça tourne pas mal oui, mais le multithread est toujours un peu à la ramasse...
Uniquement côté scheduler ou aussi à cause des applis qui ne le gèrent pas bien ?
D'ailleurs la direction qu'Intel et AMD prennent et qui consiste à tenter d'agréger plusieurs cores pour "simuler" un processeur unique plus rapide est, à mon sens, un gros désaveux pour les développeurs (en plus d'être un workaround au coup de frein sur les fréquences brutes)
Voui, voui :-/
C't'agaçant hein ?
oui, je me dis que je dois rater un truc énorme et que je devrais pouvoir la pousser encore plus.
Ou alors, ils ont mis tout à fond out-of-the box.
à suivre, je viens de rebooter le macpro, et je vais lui remettre une tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
il s'est revautré, pas grave, mais pas sans conséquences.
J'imagine.
J'avais réduit le backlog de mysqld à une valeur assez faible, ainsi que le nombre de thread max : peu de thread concurrents et impossibilité d'en mettre beaucoup en attente. Donc en théorie, un processeur rapide doit s'en sortir correctement par rapport à un processeur "lent", qui aurait du subir des tas de "too many connections". En réalité, encore une fois la sun s'en sort impeccablement, et le macpro se viande dans les grandes largeurs, et c'est lui qui a reçu des erreurs.
Strange mais bon...
Juste pour faire patienter avant que je fasse d'autres benches voilà un aperçu des résultats actuels :
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages. Par contre, on voit que la sun a la pêche, effectivement.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
In article <1hng9y8.54y046xqc52cN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant,
as-tu regardé du côté des packages proposés par MySQL, ils s'installent
très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on
évite les migraines dans les MAJ Apple).
voui, mais bon, il y'a déjà tellement de choses a tester, de
combinaisons de paramètres que je vais essayer de pas me disperser en
multipliant les versions de MySQL ;)
Certes, je te comprends.
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te
fournir je pense, est largement mieux optimisé, résultat de sa
compilation avec GCC 4 au lieu de 3.3 ?
ça tourne pas mal oui, mais le multithread est toujours un peu à la
ramasse...
Uniquement côté scheduler ou aussi à cause des applis qui ne le gèrent
pas bien ?
D'ailleurs la direction qu'Intel et AMD prennent et qui
consiste à tenter d'agréger plusieurs cores pour "simuler" un processeur
unique plus rapide est, à mon sens, un gros désaveux pour les
développeurs (en plus d'être un workaround au coup de frein sur les
fréquences brutes)
Voui, voui :-/
C't'agaçant hein ?
oui, je me dis que je dois rater un truc énorme et que je devrais
pouvoir la pousser encore plus.
Ou alors, ils ont mis tout à fond out-of-the box.
à suivre, je viens de rebooter le macpro, et je vais lui remettre une
tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
il s'est revautré, pas grave, mais pas sans conséquences.
J'imagine.
J'avais réduit le backlog de mysqld à une valeur assez faible, ainsi que
le nombre de thread max : peu de thread concurrents et impossibilité
d'en mettre beaucoup en attente. Donc en théorie, un processeur rapide
doit s'en sortir correctement par rapport à un processeur "lent", qui
aurait du subir des tas de "too many connections".
En réalité, encore une fois la sun s'en sort impeccablement, et le
macpro se viande dans les grandes largeurs, et c'est lui qui a reçu des
erreurs.
Strange mais bon...
Juste pour faire patienter avant que je fasse d'autres benches voilà un
aperçu des résultats actuels :
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec
16 threads ? c'est étrange comme comportement par rapport aux deux
autres réglages. Par contre, on voit que la sun a la pêche,
effectivement.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
In article <1hng9y8.54y046xqc52cN%, (Laurent Pertois) wrote:
Oui, mais je pense que maintenant ce sera pour Leopard. En attendant, as-tu regardé du côté des packages proposés par MySQL, ils s'installent très bien sur un Mac OS X Server sans casser le MySQL fourni (donc on évite les migraines dans les MAJ Apple).
voui, mais bon, il y'a déjà tellement de choses a tester, de combinaisons de paramètres que je vais essayer de pas me disperser en multipliant les versions de MySQL ;)
Certes, je te comprends.
Il faut dire aussi que le Mac OS X Server Universal, que Michel a du te fournir je pense, est largement mieux optimisé, résultat de sa compilation avec GCC 4 au lieu de 3.3 ?
ça tourne pas mal oui, mais le multithread est toujours un peu à la ramasse...
Uniquement côté scheduler ou aussi à cause des applis qui ne le gèrent pas bien ?
D'ailleurs la direction qu'Intel et AMD prennent et qui consiste à tenter d'agréger plusieurs cores pour "simuler" un processeur unique plus rapide est, à mon sens, un gros désaveux pour les développeurs (en plus d'être un workaround au coup de frein sur les fréquences brutes)
Voui, voui :-/
C't'agaçant hein ?
oui, je me dis que je dois rater un truc énorme et que je devrais pouvoir la pousser encore plus.
Ou alors, ils ont mis tout à fond out-of-the box.
à suivre, je viens de rebooter le macpro, et je vais lui remettre une tartine de bench dans les mâchoires.
Courage petit Mac Pro, courage :)
il s'est revautré, pas grave, mais pas sans conséquences.
J'imagine.
J'avais réduit le backlog de mysqld à une valeur assez faible, ainsi que le nombre de thread max : peu de thread concurrents et impossibilité d'en mettre beaucoup en attente. Donc en théorie, un processeur rapide doit s'en sortir correctement par rapport à un processeur "lent", qui aurait du subir des tas de "too many connections". En réalité, encore une fois la sun s'en sort impeccablement, et le macpro se viande dans les grandes largeurs, et c'est lui qui a reçu des erreurs.
Strange mais bon...
Juste pour faire patienter avant que je fasse d'autres benches voilà un aperçu des résultats actuels :
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages. Par contre, on voit que la sun a la pêche, effectivement.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski
In article <1hnghaw.109qidnalr633N%, (Laurent Pertois) wrote:
ça tourne pas mal oui, mais le multithread est toujours un peu à la ramasse...
Uniquement côté scheduler ou aussi à cause des applis qui ne le gèrent pas bien ?
ça doit se jouer dans le kernel, parce que c'est valable pour toutes les appli.
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi le backlog de threads. Le bench macpro se ramasse quand super-smack ne parvient plus à se connecter au mysqld.
évidemment, en prod, si on sait qu'on est limité en nombre de threads, on peut vouloir augmenter le back_log pour stocker plus de threads en attente.
patpro
-- http://www.patpro.net/
In article <1hnghaw.109qidnalr633N%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
ça tourne pas mal oui, mais le multithread est toujours un peu à la
ramasse...
Uniquement côté scheduler ou aussi à cause des applis qui ne le gèrent
pas bien ?
ça doit se jouer dans le kernel, parce que c'est valable pour toutes les
appli.
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec
16 threads ? c'est étrange comme comportement par rapport aux deux
autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi
le backlog de threads. Le bench macpro se ramasse quand super-smack ne
parvient plus à se connecter au mysqld.
In article <1hnghaw.109qidnalr633N%, (Laurent Pertois) wrote:
ça tourne pas mal oui, mais le multithread est toujours un peu à la ramasse...
Uniquement côté scheduler ou aussi à cause des applis qui ne le gèrent pas bien ?
ça doit se jouer dans le kernel, parce que c'est valable pour toutes les appli.
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi le backlog de threads. Le bench macpro se ramasse quand super-smack ne parvient plus à se connecter au mysqld.
évidemment, en prod, si on sait qu'on est limité en nombre de threads, on peut vouloir augmenter le back_log pour stocker plus de threads en attente.
patpro
-- http://www.patpro.net/
laurent.pertois
patpro ~ Patrick Proniewski wrote:
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi le backlog de threads. Le bench macpro se ramasse quand super-smack ne parvient plus à se connecter au mysqld.
Ah ben oui, mais ce n'est pas écrit dans la légende :)
évidemment, en prod, si on sait qu'on est limité en nombre de threads, on peut vouloir augmenter le back_log pour stocker plus de threads en attente.
Evidemment.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec
16 threads ? c'est étrange comme comportement par rapport aux deux
autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi
le backlog de threads. Le bench macpro se ramasse quand super-smack ne
parvient plus à se connecter au mysqld.
Ah ben oui, mais ce n'est pas écrit dans la légende :)
évidemment, en prod, si on sait qu'on est limité en nombre de threads,
on peut vouloir augmenter le back_log pour stocker plus de threads en
attente.
Evidemment.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi le backlog de threads. Le bench macpro se ramasse quand super-smack ne parvient plus à se connecter au mysqld.
Ah ben oui, mais ce n'est pas écrit dans la légende :)
évidemment, en prod, si on sait qu'on est limité en nombre de threads, on peut vouloir augmenter le back_log pour stocker plus de threads en attente.
Evidemment.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski
In article <1hngj97.ijqd4dofxn5rN%, (Laurent Pertois) wrote:
patpro ~ Patrick Proniewski wrote:
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi le backlog de threads. Le bench macpro se ramasse quand super-smack ne parvient plus à se connecter au mysqld.
Ah ben oui, mais ce n'est pas écrit dans la légende :)
ca ferait des sacrées légendes si je mettais tout le my.cnf dedans ;)
patpro
-- http://www.patpro.net/
In article <1hngj97.ijqd4dofxn5rN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec
16 threads ? c'est étrange comme comportement par rapport aux deux
autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi
le backlog de threads. Le bench macpro se ramasse quand super-smack ne
parvient plus à se connecter au mysqld.
Ah ben oui, mais ce n'est pas écrit dans la légende :)
ca ferait des sacrées légendes si je mettais tout le my.cnf dedans ;)
In article <1hngj97.ijqd4dofxn5rN%, (Laurent Pertois) wrote:
patpro ~ Patrick Proniewski wrote:
Marrant. La ligne bleue qui se vautre, c'est bien celle du Mac Pro avec 16 threads ? c'est étrange comme comportement par rapport aux deux autres réglages.
je ne change pas que le nombre de threads concurrents, je change aussi le backlog de threads. Le bench macpro se ramasse quand super-smack ne parvient plus à se connecter au mysqld.
Ah ben oui, mais ce n'est pas écrit dans la légende :)
ca ferait des sacrées légendes si je mettais tout le my.cnf dedans ;)
patpro
-- http://www.patpro.net/
laurent.pertois
patpro ~ Patrick Proniewski wrote:
Ah ben oui, mais ce n'est pas écrit dans la légende :)
ca ferait des sacrées légendes si je mettais tout le my.cnf dedans ;)
Rhoooohhhhh :)
Oui, bon, okokok...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
Ah ben oui, mais ce n'est pas écrit dans la légende :)
ca ferait des sacrées légendes si je mettais tout le my.cnf dedans ;)
Rhoooohhhhh :)
Oui, bon, okokok...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ah ben oui, mais ce n'est pas écrit dans la légende :)
ca ferait des sacrées légendes si je mettais tout le my.cnf dedans ;)
Rhoooohhhhh :)
Oui, bon, okokok...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
