Mon iMac G4 se met progressivement à perdre de la vitesse et on en
arrive assez vite à attendre plusieurs secondes avant l'exécution de
chaque commande qque soit l'appli. , avec à chaque fois déclenchement de
la petite roue collorée qui tourne de plus en plus longtemps. On finit
par ne plus avoir de réponse à rien d'où obligation de redémarrage
"Hard". Aprés quoi tout semble être rentré dans l'ordre mais non à
nouveau çà repart.
Il semble que le gravage, la mise en veille soient des facteurs
declenchants ou accélérants. J'ai l'impression que cela a démarré avec
la MàJ 10.3.4 mais difficile d'être affirmatif.
J'ai tout essayé, du moins ce que je connais : réinit. de la PRam,
réparation des autorisations, les scripts "cron", virer tous les caches,
vérif du disque avec utilitaire de disque ..... J'en suis là, un peu au
bout de mes modestes connaissances. Peut-être y a-t-il des fichiers
"préf" à virer mais j'hésite un peu (lesquels ?)
Ce qui m'interroge aussi c'est que le iMac du collègue au boulot (même
machine, même config) commence à présenter les mêmes symptomes !
Merci de votre aide
--
Cordialement!... A+
JLL (sans les chiffres pour me joindre)
En fait, c'est qu'une expression entre <> doit avoir un format conforme, et une référence d'un message n'a pas ce format là. MacSOUP utilise une bidouille non conforme. Pour avoir une vraie URL il faut mettre news: et escaper les caractère spéciaux comme % qui sont courant dans les ID. Ce problème me fait penser aux utilisateurs d'IE sur Windows qui pensent que parce que la page qu'ils affichent semble correcte, le code HTML qui l'a généré est conforme au standard et que tout le monde saura la lire.
Peux-tu stp nous donner un exemple d'URL conforme ? C'est pas que ton explication ne soit pas claire, mais ça aiderait quand-même. Merci :)
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Eric Lévénez <news@levenez.com> wrote:
En fait, c'est qu'une expression entre <> doit avoir un format conforme, et
une référence d'un message n'a pas ce format là. MacSOUP utilise une
bidouille non conforme. Pour avoir une vraie URL il faut mettre news: et
escaper les caractère spéciaux comme % qui sont courant dans les ID. Ce
problème me fait penser aux utilisateurs d'IE sur Windows qui pensent que
parce que la page qu'ils affichent semble correcte, le code HTML qui l'a
généré est conforme au standard et que tout le monde saura la lire.
Peux-tu stp nous donner un exemple d'URL conforme ?
C'est pas que ton explication ne soit pas claire, mais ça aiderait
quand-même.
Merci :)
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
En fait, c'est qu'une expression entre <> doit avoir un format conforme, et une référence d'un message n'a pas ce format là. MacSOUP utilise une bidouille non conforme. Pour avoir une vraie URL il faut mettre news: et escaper les caractère spéciaux comme % qui sont courant dans les ID. Ce problème me fait penser aux utilisateurs d'IE sur Windows qui pensent que parce que la page qu'ils affichent semble correcte, le code HTML qui l'a généré est conforme au standard et que tout le monde saura la lire.
Peux-tu stp nous donner un exemple d'URL conforme ? C'est pas que ton explication ne soit pas claire, mais ça aiderait quand-même. Merci :)
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
FiLH
(Macady) writes:
FiLH wrote:
Lancer Moniteur d'activité Cliquer sur % pour avoir les processus dans l'ordre décroissant d'utilisation du cpu.
Deux cas : soit un seul processus prend beaucoup de pourcentage Soit plusieurs processus se partagent des pourcentages similaires.
Regarder en bas : noter les % utilisateur, Systeme Inactif.
Regarder les différentes activités.
Sinon Ouvrir console Voir si des messages se répètent apparaissent au fur et à mesure que la machine ralenti.
Merci pour ces conseils.
Depuis hier cela semble aller mieux mais je ne sais pas pourquoi donc risque de rechute !....
Seuls indices, j'ai fait un redémarrage avec réinitialisation de la PRAM mais en attendant 3 "carillons" avant de relacher. Du temps de OS 9 il
Sérieusement je doute qu'il y ait de rapport entre les deux. C'est vraiment deux niveaux différents.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
news77jll@tele2.fr (Macady) writes:
FiLH <filh@filh.org> wrote:
Lancer Moniteur d'activité Cliquer sur % pour avoir les processus dans
l'ordre décroissant d'utilisation du cpu.
Deux cas : soit un seul processus prend beaucoup de pourcentage
Soit plusieurs processus se partagent des pourcentages similaires.
Regarder en bas : noter les % utilisateur, Systeme Inactif.
Regarder les différentes activités.
Sinon
Ouvrir console
Voir si des messages se répètent apparaissent au fur et à mesure que
la machine ralenti.
Merci pour ces conseils.
Depuis hier cela semble aller mieux mais je ne sais pas pourquoi donc
risque de rechute !....
Seuls indices, j'ai fait un redémarrage avec réinitialisation de la PRAM
mais en attendant 3 "carillons" avant de relacher. Du temps de OS 9 il
Sérieusement je doute qu'il y ait de rapport entre les deux. C'est
vraiment deux niveaux différents.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Lancer Moniteur d'activité Cliquer sur % pour avoir les processus dans l'ordre décroissant d'utilisation du cpu.
Deux cas : soit un seul processus prend beaucoup de pourcentage Soit plusieurs processus se partagent des pourcentages similaires.
Regarder en bas : noter les % utilisateur, Systeme Inactif.
Regarder les différentes activités.
Sinon Ouvrir console Voir si des messages se répètent apparaissent au fur et à mesure que la machine ralenti.
Merci pour ces conseils.
Depuis hier cela semble aller mieux mais je ne sais pas pourquoi donc risque de rechute !....
Seuls indices, j'ai fait un redémarrage avec réinitialisation de la PRAM mais en attendant 3 "carillons" avant de relacher. Du temps de OS 9 il
Sérieusement je doute qu'il y ait de rapport entre les deux. C'est vraiment deux niveaux différents.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FiLH
(Macady) writes:
Macady wrote:
Merci pour ces conseils.
Depuis hier cela semble aller mieux mais je ne sais pas pourquoi donc risque de rechute !....
Effectivement !...:-(
Qqs nouvelles du front !...
Peut-être ai-je trouvé qqchose. Grace au visualiseur d'activité (et avec de la patience) j'ai constaté que pendant la crise, sans aucune appli. lancée, le système était occupé à 80 voir 90 %. Or la seule appli "lancée" en arrière plan, que j'avais un peu oubliée, est SnapzProX. Bizarrement celle-ci avait droit à 3 lignes dans le visualiseur : une
C'est pas bizarre : un soft peut lancer plusieurs processus.
"normale" avec l'icône et 0 à 1 % plus deux autres sans icônes et qui elles montaient jusqu'à des 40 voir 45 %. Donc Reflexe mise à jour en
Ah ben ce qui nous fait 90% du temps cpu. Et hop... un mac qui rame...
Chez moi parfois c'est une page web qui fout Safari hors de lui, quand je trouve enfin laquelle tout redevient calme.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
news77jll@tele2.fr (Macady) writes:
Macady <news77jll@tele2.fr> wrote:
Merci pour ces conseils.
Depuis hier cela semble aller mieux mais je ne sais pas pourquoi donc
risque de rechute !....
Effectivement !...:-(
Qqs nouvelles du front !...
Peut-être ai-je trouvé qqchose. Grace au visualiseur d'activité (et avec
de la patience) j'ai constaté que pendant la crise, sans aucune appli.
lancée, le système était occupé à 80 voir 90 %. Or la seule appli
"lancée" en arrière plan, que j'avais un peu oubliée, est SnapzProX.
Bizarrement celle-ci avait droit à 3 lignes dans le visualiseur : une
C'est pas bizarre : un soft peut lancer plusieurs processus.
"normale" avec l'icône et 0 à 1 % plus deux autres sans icônes et qui
elles montaient jusqu'à des 40 voir 45 %. Donc Reflexe mise à jour en
Ah ben ce qui nous fait 90% du temps cpu. Et hop... un mac qui rame...
Chez moi parfois c'est une page web qui fout Safari hors de lui, quand
je trouve enfin laquelle tout redevient calme.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Depuis hier cela semble aller mieux mais je ne sais pas pourquoi donc risque de rechute !....
Effectivement !...:-(
Qqs nouvelles du front !...
Peut-être ai-je trouvé qqchose. Grace au visualiseur d'activité (et avec de la patience) j'ai constaté que pendant la crise, sans aucune appli. lancée, le système était occupé à 80 voir 90 %. Or la seule appli "lancée" en arrière plan, que j'avais un peu oubliée, est SnapzProX. Bizarrement celle-ci avait droit à 3 lignes dans le visualiseur : une
C'est pas bizarre : un soft peut lancer plusieurs processus.
"normale" avec l'icône et 0 à 1 % plus deux autres sans icônes et qui elles montaient jusqu'à des 40 voir 45 %. Donc Reflexe mise à jour en
Ah ben ce qui nous fait 90% du temps cpu. Et hop... un mac qui rame...
Chez moi parfois c'est une page web qui fout Safari hors de lui, quand je trouve enfin laquelle tout redevient calme.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Eric Lévénez
Le 21/06/04 10:35, dans <1gfq71z.n6so6zzd6u9sN%, « Nicolas MICHEL » a écrit :
Eric Lévénez wrote:
En fait, c'est qu'une expression entre <> doit avoir un format conforme, et une référence d'un message n'a pas ce format là. MacSOUP utilise une bidouille non conforme. Pour avoir une vraie URL il faut mettre news: et escaper les caractère spéciaux comme % qui sont courant dans les ID. Ce problème me fait penser aux utilisateurs d'IE sur Windows qui pensent que parce que la page qu'ils affichent semble correcte, le code HTML qui l'a généré est conforme au standard et que tout le monde saura la lire.
Peux-tu stp nous donner un exemple d'URL conforme ?
Voir la RFC 1738 et 2396, les méthodes news: et nntp:, la seconde méthode semble la meilleure car on indique le serveur où trouver la news.
Pour un exemple : <http://www.levenez.com/NeXTSTEP/>, paragraphe Usernet. Il faut bien sûr un browser qui sache gérer la méthode news:. Dans mon exemple il s'ait juste d'indiquer un groupe Usenet et pas un article particulier dans le groupe. Les RFC ci-dessus donnent les différentes syntaxes pour cela.
C'est pas que ton explication ne soit pas claire, mais ça aiderait quand-même.
Le problème de définir un ID de news sans indiquer le nom du serveur est que tous les serveurs n'ont pas forcément seedés la news et elle peut apparaître comme inconnu. Il est donc préférable d'indiquer un nom de serveur public par la méthode 2.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 21/06/04 10:35, dans <1gfq71z.n6so6zzd6u9sN%Nicolas.MICHEL@BonBon.net>,
« Nicolas MICHEL » <Nicolas.MICHEL@BonBon.net> a écrit :
Eric Lévénez <news@levenez.com> wrote:
En fait, c'est qu'une expression entre <> doit avoir un format conforme, et
une référence d'un message n'a pas ce format là. MacSOUP utilise une
bidouille non conforme. Pour avoir une vraie URL il faut mettre news: et
escaper les caractère spéciaux comme % qui sont courant dans les ID. Ce
problème me fait penser aux utilisateurs d'IE sur Windows qui pensent que
parce que la page qu'ils affichent semble correcte, le code HTML qui l'a
généré est conforme au standard et que tout le monde saura la lire.
Peux-tu stp nous donner un exemple d'URL conforme ?
Voir la RFC 1738 et 2396, les méthodes news: et nntp:, la seconde méthode
semble la meilleure car on indique le serveur où trouver la news.
Pour un exemple : <http://www.levenez.com/NeXTSTEP/>, paragraphe Usernet. Il
faut bien sûr un browser qui sache gérer la méthode news:. Dans mon exemple
il s'ait juste d'indiquer un groupe Usenet et pas un article particulier
dans le groupe. Les RFC ci-dessus donnent les différentes syntaxes pour
cela.
C'est pas que ton explication ne soit pas claire, mais ça aiderait
quand-même.
Le problème de définir un ID de news sans indiquer le nom du serveur est que
tous les serveurs n'ont pas forcément seedés la news et elle peut apparaître
comme inconnu. Il est donc préférable d'indiquer un nom de serveur public
par la méthode 2.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 21/06/04 10:35, dans <1gfq71z.n6so6zzd6u9sN%, « Nicolas MICHEL » a écrit :
Eric Lévénez wrote:
En fait, c'est qu'une expression entre <> doit avoir un format conforme, et une référence d'un message n'a pas ce format là. MacSOUP utilise une bidouille non conforme. Pour avoir une vraie URL il faut mettre news: et escaper les caractère spéciaux comme % qui sont courant dans les ID. Ce problème me fait penser aux utilisateurs d'IE sur Windows qui pensent que parce que la page qu'ils affichent semble correcte, le code HTML qui l'a généré est conforme au standard et que tout le monde saura la lire.
Peux-tu stp nous donner un exemple d'URL conforme ?
Voir la RFC 1738 et 2396, les méthodes news: et nntp:, la seconde méthode semble la meilleure car on indique le serveur où trouver la news.
Pour un exemple : <http://www.levenez.com/NeXTSTEP/>, paragraphe Usernet. Il faut bien sûr un browser qui sache gérer la méthode news:. Dans mon exemple il s'ait juste d'indiquer un groupe Usenet et pas un article particulier dans le groupe. Les RFC ci-dessus donnent les différentes syntaxes pour cela.
C'est pas que ton explication ne soit pas claire, mais ça aiderait quand-même.
Le problème de définir un ID de news sans indiquer le nom du serveur est que tous les serveurs n'ont pas forcément seedés la news et elle peut apparaître comme inconnu. Il est donc préférable d'indiquer un nom de serveur public par la méthode 2.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
