Depuis quelques temps (10.5 pour être précis), 2 choses m'agace
sérieusement...
1/ l'obligation de plus en plus courante de redémarrer pour effectuer
une mise à jour (Safari par exemple)... J'imagine qu'il doit y avoir de
(bonnes) raisons mais c'est pénible...
Je me rappelle avec bonheur le doux temps de 10.3 ou l'on pouvait
effectuer toutes sortes de mises à jour sans avoir de redémarrer quoique
ce soit, ni même parfois quitter.
Le nombre de mise à jour redémarrante augmente me semble-t'il et ce
n'est pas un progrès.
2/ Le mot de passe d'ouverture de session. J'avais lu quelque part qu'il
y avait une faille de sécurité lors de la saisie du mot de passe de
session avant que la zone de saisie n'apparaisse (une histoire de
droits)... Pour "corriger" cette faille, il faut désormais attendre que
la zone de saisie apparaisse (après avoir choisit un utilisateur) pour
saisir. Toute saisie anticipée est irrémédiablement rejetté.
Et pourtant la zone de saisie n'apparait pas tout de suite, j'ai parfois
le temps de saisir mon mot de passe entier avant qu'elle n'apparaisse...
Ca m'agace cart j'ai tellement l'habitude de saisir mon mot de passe et
de faire ENTER que depuis 10.5 je me retrouve avec un bout de mot de
passe, des beeps et l'obligation de tout ressaisir...
Le 7/22/09 8:58 AM, Patrick Stadelmann a écrit : > > Les MàJ de Safari incluent généralement des MàJ de librairies système, > en particulier WebKit (moteur de rendu HTML). Le redémarrage permet de > s'assurer qu'il n'y ait pas des bouts de l'ancienne versions qui > resteraient en mémoire car utilisé par des applications ou le système.
Et donc, on ne peut faire tourner plusieurs versions de Safari sur le même poste ?
S'il s'agit de Safari "normaux", ils vont tous utiliser le même WebKit. Ca peut fonctionner ou pas selon les versions. Sinon, on peut avoir des Safari qui intègrent leur propre copie de WebKit.
(et sans doute pas/jamais en même temps)
Dans des sessions différentes, on peut. Dans la même session, il risque d'y avoir des conflits d'accès au préférences entre autres.
à moins qu'en initiant autant d'user que de versions de Safari ? Mézalor ce webkit il serait individualisé par session ?
Non, toutes les sessions utilisent le même WebKit, celui du système (sauf s'il y a un WebKit dans Safari.app).
Patrick -- Patrick Stadelmann
In article <4a681ef1$0$12645$ba4acef3@news.orange.fr>,
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:
Le 7/22/09 8:58 AM, Patrick Stadelmann a écrit :
>
> Les MàJ de Safari incluent généralement des MàJ de librairies système,
> en particulier WebKit (moteur de rendu HTML). Le redémarrage permet de
> s'assurer qu'il n'y ait pas des bouts de l'ancienne versions qui
> resteraient en mémoire car utilisé par des applications ou le système.
Et donc, on ne peut faire tourner plusieurs versions de Safari sur le
même poste ?
S'il s'agit de Safari "normaux", ils vont tous utiliser le même WebKit.
Ca peut fonctionner ou pas selon les versions. Sinon, on peut avoir des
Safari qui intègrent leur propre copie de WebKit.
(et sans doute pas/jamais en même temps)
Dans des sessions différentes, on peut. Dans la même session, il risque
d'y avoir des conflits d'accès au préférences entre autres.
à moins qu'en initiant autant d'user que de versions de Safari ?
Mézalor ce webkit il serait individualisé par session ?
Non, toutes les sessions utilisent le même WebKit, celui du système
(sauf s'il y a un WebKit dans Safari.app).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Le 7/22/09 8:58 AM, Patrick Stadelmann a écrit : > > Les MàJ de Safari incluent généralement des MàJ de librairies système, > en particulier WebKit (moteur de rendu HTML). Le redémarrage permet de > s'assurer qu'il n'y ait pas des bouts de l'ancienne versions qui > resteraient en mémoire car utilisé par des applications ou le système.
Et donc, on ne peut faire tourner plusieurs versions de Safari sur le même poste ?
S'il s'agit de Safari "normaux", ils vont tous utiliser le même WebKit. Ca peut fonctionner ou pas selon les versions. Sinon, on peut avoir des Safari qui intègrent leur propre copie de WebKit.
(et sans doute pas/jamais en même temps)
Dans des sessions différentes, on peut. Dans la même session, il risque d'y avoir des conflits d'accès au préférences entre autres.
à moins qu'en initiant autant d'user que de versions de Safari ? Mézalor ce webkit il serait individualisé par session ?
Non, toutes les sessions utilisent le même WebKit, celui du système (sauf s'il y a un WebKit dans Safari.app).
Patrick -- Patrick Stadelmann
pdorange
SAM wrote:
> Les MàJ de Safari incluent généralement des MàJ de librairies système, > en particulier WebKit (moteur de rendu HTML). Le redémarrage permet de > s'assurer qu'il n'y ait pas des bouts de l'ancienne versions qui > resteraient en mémoire car utilisé par des applications ou le système.
Et donc, on ne peut faire tourner plusieurs versions de Safari sur le même poste ? (et sans doute pas/jamais en même temps)
Non tu ne peux pas en effet.
[...] à moins qu'en initiant autant d'user que de versions de Safari ?
Non pus
Mézalor ce webkit il serait individualisé par session ?
Non
Sinon comment juger de Safari.2 s'il est épaulé par le webkit.4
Tu ne peux pas installer Safari 2 sur un système qui accepte Safari 4.
Safari et Webkit sont "entremélés". Grossièrement, le webkit gère l'analyse et l'affichage (rendu) du HTML, javascript... alors que Safari gère plutot l'interface utilisateur.
Il reste possible de tester des versions béta du Webkit (mais a réserver aux utilisateurs avertis) grace au nightly builds du WebKit qui fournissent un navigateur simplifié et autonome (webkit intégré, non partagé).
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:
> Les MàJ de Safari incluent généralement des MàJ de librairies système,
> en particulier WebKit (moteur de rendu HTML). Le redémarrage permet de
> s'assurer qu'il n'y ait pas des bouts de l'ancienne versions qui
> resteraient en mémoire car utilisé par des applications ou le système.
Et donc, on ne peut faire tourner plusieurs versions de Safari sur le
même poste ?
(et sans doute pas/jamais en même temps)
Non tu ne peux pas en effet.
[...]
à moins qu'en initiant autant d'user que de versions de Safari ?
Non pus
Mézalor ce webkit il serait individualisé par session ?
Non
Sinon comment juger de Safari.2 s'il est épaulé par le webkit.4
Tu ne peux pas installer Safari 2 sur un système qui accepte Safari 4.
Safari et Webkit sont "entremélés".
Grossièrement, le webkit gère l'analyse et l'affichage (rendu) du HTML,
javascript... alors que Safari gère plutot l'interface utilisateur.
Il reste possible de tester des versions béta du Webkit (mais a réserver
aux utilisateurs avertis) grace au nightly builds du WebKit qui
fournissent un navigateur simplifié et autonome (webkit intégré, non
partagé).
> Les MàJ de Safari incluent généralement des MàJ de librairies système, > en particulier WebKit (moteur de rendu HTML). Le redémarrage permet de > s'assurer qu'il n'y ait pas des bouts de l'ancienne versions qui > resteraient en mémoire car utilisé par des applications ou le système.
Et donc, on ne peut faire tourner plusieurs versions de Safari sur le même poste ? (et sans doute pas/jamais en même temps)
Non tu ne peux pas en effet.
[...] à moins qu'en initiant autant d'user que de versions de Safari ?
Non pus
Mézalor ce webkit il serait individualisé par session ?
Non
Sinon comment juger de Safari.2 s'il est épaulé par le webkit.4
Tu ne peux pas installer Safari 2 sur un système qui accepte Safari 4.
Safari et Webkit sont "entremélés". Grossièrement, le webkit gère l'analyse et l'affichage (rendu) du HTML, javascript... alors que Safari gère plutot l'interface utilisateur.
Il reste possible de tester des versions béta du Webkit (mais a réserver aux utilisateurs avertis) grace au nightly builds du WebKit qui fournissent un navigateur simplifié et autonome (webkit intégré, non partagé).
> > > > Du coup, j'ai switché direct pour Firefox qui -lui- n'emmerde pas > > > l'utilisateur. > > > > Exact. > > Ben si, il demande un mot de passe à l'ouverture de la session > -- en fait environ une minute après, quand tu as commencé à travailler > avec ;-)
??? Il ne me demande rien moi.
Moi non plus. Je ne vois pas pourquoi il en demanderait un d'ailleurs...
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
>
> > > Du coup, j'ai switché direct pour Firefox qui -lui- n'emmerde pas
> > > l'utilisateur.
> >
> > Exact.
>
> Ben si, il demande un mot de passe à l'ouverture de la session
> -- en fait environ une minute après, quand tu as commencé à travailler
> avec ;-)
???
Il ne me demande rien moi.
Moi non plus. Je ne vois pas pourquoi il en demanderait un d'ailleurs...
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
> > > > Du coup, j'ai switché direct pour Firefox qui -lui- n'emmerde pas > > > l'utilisateur. > > > > Exact. > > Ben si, il demande un mot de passe à l'ouverture de la session > -- en fait environ une minute après, quand tu as commencé à travailler > avec ;-)
??? Il ne me demande rien moi.
Moi non plus. Je ne vois pas pourquoi il en demanderait un d'ailleurs...
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Paul Gaborit
À (at) Thu, 23 Jul 2009 11:05:20 +0200, Patrick Stadelmann écrivait (wrote):
C'est préférable à mon avis. L'installation se fait ainsi dans les meilleures conditions. Et ce n'est que pour les MàJ système (dont Safari pour les raisons déjà discutées).
[...]
C'était peut-être agréable pour l'utilisateur, mais AMHA potentiellement problématique, c'est du moins la seule raison qui puisse expliquer le changement d'approche.
En informatique, pour les concepteurs et les développeurs, les termes "meilleures conditions" ou "potentiellement problématique" n'ont pas de sens. Soit le redémarrage est nécessaire soit il ne l'est pas.
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire dans le noyau pas plus d'ailleurs qu'un quicktime.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 23 Jul 2009 11:05:20 +0200,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
C'est préférable à mon avis. L'installation se fait ainsi dans les
meilleures conditions. Et ce n'est que pour les MàJ système (dont Safari
pour les raisons déjà discutées).
[...]
C'était peut-être agréable pour l'utilisateur, mais AMHA potentiellement
problématique, c'est du moins la seule raison qui puisse expliquer le
changement d'approche.
En informatique, pour les concepteurs et les développeurs, les termes
"meilleures conditions" ou "potentiellement problématique" n'ont pas
de sens. Soit le redémarrage est nécessaire soit il ne l'est pas.
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce
celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire
dans le noyau pas plus d'ailleurs qu'un quicktime.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 23 Jul 2009 11:05:20 +0200, Patrick Stadelmann écrivait (wrote):
C'est préférable à mon avis. L'installation se fait ainsi dans les meilleures conditions. Et ce n'est que pour les MàJ système (dont Safari pour les raisons déjà discutées).
[...]
C'était peut-être agréable pour l'utilisateur, mais AMHA potentiellement problématique, c'est du moins la seule raison qui puisse expliquer le changement d'approche.
En informatique, pour les concepteurs et les développeurs, les termes "meilleures conditions" ou "potentiellement problématique" n'ont pas de sens. Soit le redémarrage est nécessaire soit il ne l'est pas.
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire dans le noyau pas plus d'ailleurs qu'un quicktime.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
pdorange
Patrick Stadelmann wrote:
> Safari 3 ou 2, si il demandait (parfois) de redémarrer, cela n'avait > rien d'obligatoire et pouvait être différé sans soucis, cad que l'on > pouvait continuer a travailler pendant le chargement de l'installeur et > même pendant l'installation.
C'était peut-être agréable pour l'utilisateur, mais AMHA potentiellement problématique, c'est du moins la seule raison qui puisse expliquer le changement d'approche.
Techniquement il est aussi possible d'imaginer (bien que bizarre) qu'un bout du webkit soit en kext (kernel extension) ce qui nécessiterait de facto un reboot. Mais c'est plutot réservé aux pilotes matériels.
Quand au potentiellement problématique, tout est possible mais depuis Safari 2 je n'ai pas rencontré le moindre problème de maj (sans reboot) et je ne me rapelle pas en avoir entendu parlé ici ou ailleurs...
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Safari 3 ou 2, si il demandait (parfois) de redémarrer, cela n'avait
> rien d'obligatoire et pouvait être différé sans soucis, cad que l'on
> pouvait continuer a travailler pendant le chargement de l'installeur et
> même pendant l'installation.
C'était peut-être agréable pour l'utilisateur, mais AMHA potentiellement
problématique, c'est du moins la seule raison qui puisse expliquer le
changement d'approche.
Techniquement il est aussi possible d'imaginer (bien que bizarre) qu'un
bout du webkit soit en kext (kernel extension) ce qui nécessiterait de
facto un reboot. Mais c'est plutot réservé aux pilotes matériels.
Quand au potentiellement problématique, tout est possible mais depuis
Safari 2 je n'ai pas rencontré le moindre problème de maj (sans reboot)
et je ne me rapelle pas en avoir entendu parlé ici ou ailleurs...
> Safari 3 ou 2, si il demandait (parfois) de redémarrer, cela n'avait > rien d'obligatoire et pouvait être différé sans soucis, cad que l'on > pouvait continuer a travailler pendant le chargement de l'installeur et > même pendant l'installation.
C'était peut-être agréable pour l'utilisateur, mais AMHA potentiellement problématique, c'est du moins la seule raison qui puisse expliquer le changement d'approche.
Techniquement il est aussi possible d'imaginer (bien que bizarre) qu'un bout du webkit soit en kext (kernel extension) ce qui nécessiterait de facto un reboot. Mais c'est plutot réservé aux pilotes matériels.
Quand au potentiellement problématique, tout est possible mais depuis Safari 2 je n'ai pas rencontré le moindre problème de maj (sans reboot) et je ne me rapelle pas en avoir entendu parlé ici ou ailleurs...
Moi non plus. Je ne vois pas pourquoi il en demanderait un d'ailleurs...
Pour son gestionnaire de mots de passe, mais sauf erreur il est déverrouillé par défaut.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article , Paul Gaborit wrote:
En informatique, pour les concepteurs et les développeurs, les termes "meilleures conditions" ou "potentiellement problématique" n'ont pas de sens. Soit le redémarrage est nécessaire soit il ne l'est pas.
Il y a une différence entre "nécessaire parce que le système est inutilisable sinon" et "nécessaire pour éviter que dans des rares cas une application plante" après la MàJ.
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire dans le noyau pas plus d'ailleurs qu'un quicktime.
Qu'est-ce qui te fait dire que le WebKit est dans le noyau ? AMHA, c'est une librairie système qui peut-être utilisée par n'importe quelle application, et que le redémarrage permet de s'assurer que les applications ne vont pas se retrouver à utiliser deux versions différentes et potentiellement incompatibles.
Patrick -- Patrick Stadelmann
In article <wt97hxzafok.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
En informatique, pour les concepteurs et les développeurs, les termes
"meilleures conditions" ou "potentiellement problématique" n'ont pas
de sens. Soit le redémarrage est nécessaire soit il ne l'est pas.
Il y a une différence entre "nécessaire parce que le système est
inutilisable sinon" et "nécessaire pour éviter que dans des rares cas
une application plante" après la MàJ.
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce
celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire
dans le noyau pas plus d'ailleurs qu'un quicktime.
Qu'est-ce qui te fait dire que le WebKit est dans le noyau ? AMHA, c'est
une librairie système qui peut-être utilisée par n'importe quelle
application, et que le redémarrage permet de s'assurer que les
applications ne vont pas se retrouver à utiliser deux versions
différentes et potentiellement incompatibles.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
En informatique, pour les concepteurs et les développeurs, les termes "meilleures conditions" ou "potentiellement problématique" n'ont pas de sens. Soit le redémarrage est nécessaire soit il ne l'est pas.
Il y a une différence entre "nécessaire parce que le système est inutilisable sinon" et "nécessaire pour éviter que dans des rares cas une application plante" après la MàJ.
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire dans le noyau pas plus d'ailleurs qu'un quicktime.
Qu'est-ce qui te fait dire que le WebKit est dans le noyau ? AMHA, c'est une librairie système qui peut-être utilisée par n'importe quelle application, et que le redémarrage permet de s'assurer que les applications ne vont pas se retrouver à utiliser deux versions différentes et potentiellement incompatibles.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1j3b12s.10td0h81ckvxh2N%, (Pierre-Alain Dorange) wrote:
Techniquement il est aussi possible d'imaginer (bien que bizarre) qu'un bout du webkit soit en kext (kernel extension) ce qui nécessiterait de facto un reboot. Mais c'est plutot réservé aux pilotes matériels.
Non, il n'y a pas de kext dans WebKit, il suffit de regarder la BOM de l'installeur. De plus, Mac OS X supporte l'ajout et la suppression de kext dans le noyau sans redémarrage ! Alors qu'il n'y a rien de tel pour les librairies à ma connaissance...
Quand au potentiellement problématique, tout est possible mais depuis Safari 2 je n'ai pas rencontré le moindre problème de maj (sans reboot) et je ne me rapelle pas en avoir entendu parlé ici ou ailleurs...
Vu que le problème disparaîtra au prochain démarrage, je doute qu'on en entende beaucoup parler. Ca ne change rien au fait que de remplacer une librairie qui est en cours d'utilisation n'est pas une bonne idée. Le seul problème, c'est quand on dit "Une MàJ de Safari nécessite de redémarrer" alors qu'en fait c'est en plus une MàJ d'une partie du système.
Patrick -- Patrick Stadelmann
In article <1j3b12s.10td0h81ckvxh2N%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
Techniquement il est aussi possible d'imaginer (bien que bizarre) qu'un
bout du webkit soit en kext (kernel extension) ce qui nécessiterait de
facto un reboot. Mais c'est plutot réservé aux pilotes matériels.
Non, il n'y a pas de kext dans WebKit, il suffit de regarder la BOM de
l'installeur. De plus, Mac OS X supporte l'ajout et la suppression de
kext dans le noyau sans redémarrage ! Alors qu'il n'y a rien de tel pour
les librairies à ma connaissance...
Quand au potentiellement problématique, tout est possible mais depuis
Safari 2 je n'ai pas rencontré le moindre problème de maj (sans reboot)
et je ne me rapelle pas en avoir entendu parlé ici ou ailleurs...
Vu que le problème disparaîtra au prochain démarrage, je doute qu'on en
entende beaucoup parler. Ca ne change rien au fait que de remplacer une
librairie qui est en cours d'utilisation n'est pas une bonne idée. Le
seul problème, c'est quand on dit "Une MàJ de Safari nécessite de
redémarrer" alors qu'en fait c'est en plus une MàJ d'une partie du
système.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1j3b12s.10td0h81ckvxh2N%, (Pierre-Alain Dorange) wrote:
Techniquement il est aussi possible d'imaginer (bien que bizarre) qu'un bout du webkit soit en kext (kernel extension) ce qui nécessiterait de facto un reboot. Mais c'est plutot réservé aux pilotes matériels.
Non, il n'y a pas de kext dans WebKit, il suffit de regarder la BOM de l'installeur. De plus, Mac OS X supporte l'ajout et la suppression de kext dans le noyau sans redémarrage ! Alors qu'il n'y a rien de tel pour les librairies à ma connaissance...
Quand au potentiellement problématique, tout est possible mais depuis Safari 2 je n'ai pas rencontré le moindre problème de maj (sans reboot) et je ne me rapelle pas en avoir entendu parlé ici ou ailleurs...
Vu que le problème disparaîtra au prochain démarrage, je doute qu'on en entende beaucoup parler. Ca ne change rien au fait que de remplacer une librairie qui est en cours d'utilisation n'est pas une bonne idée. Le seul problème, c'est quand on dit "Une MàJ de Safari nécessite de redémarrer" alors qu'en fait c'est en plus une MàJ d'une partie du système.
Patrick -- Patrick Stadelmann
benoit.sansspam
Paul Gaborit wrote:
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire dans le noyau pas plus d'ailleurs qu'un quicktime.
Le WebKit est utilisé par le Finder (ou le système) pour des aperçus dans les fenêtres ou pour plus certainement par le « coup d'½il » que pas mal de monde utilise (Finder, Mail...). À partir du moment o le Finder s'en sert il faut que tous les Finder soient relancés pour éviter tout problème.
Ensuite. Imaginons qu'il y ait une màj pour le WebKit, que rien ne soit installé parce que des applis qui tournent s'en servent et qu'une deuxième màj soit installées concernant le WebKit plus d'autres éléments. Cela devient vite le souk dans la gestion de ces nouveaux codes et le plantage au reboot suivant pend au nez.
-- Benoît
Avec des fumeurs c'est difficile de s'arrêter. Avec des branleurs, là, par contre, c'est difficile de continuer.
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce
celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire
dans le noyau pas plus d'ailleurs qu'un quicktime.
Le WebKit est utilisé par le Finder (ou le système) pour des
aperçus dans les fenêtres ou pour plus certainement par le « coup
d'½il » que pas mal de monde utilise (Finder, Mail...). À partir du
moment o le Finder s'en sert il faut que tous les Finder soient relancés
pour éviter tout problème.
Ensuite. Imaginons qu'il y ait une màj pour le WebKit, que rien
ne soit installé parce que des applis qui tournent s'en servent et
qu'une deuxième màj soit installées concernant le WebKit plus d'autres
éléments. Cela devient vite le souk dans la gestion de ces nouveaux
codes et le plantage au reboot suivant pend au nez.
--
Benoît
Avec des fumeurs c'est difficile de s'arrêter. Avec des branleurs,
là, par contre, c'est difficile de continuer.
Ce qui est problématique, c'est que la mise à jour d'un webkit (fut-ce celui d'Apple) nécessite de redémarrer. Un webkit n'a rien à faire dans le noyau pas plus d'ailleurs qu'un quicktime.
Le WebKit est utilisé par le Finder (ou le système) pour des aperçus dans les fenêtres ou pour plus certainement par le « coup d'½il » que pas mal de monde utilise (Finder, Mail...). À partir du moment o le Finder s'en sert il faut que tous les Finder soient relancés pour éviter tout problème.
Ensuite. Imaginons qu'il y ait une màj pour le WebKit, que rien ne soit installé parce que des applis qui tournent s'en servent et qu'une deuxième màj soit installées concernant le WebKit plus d'autres éléments. Cela devient vite le souk dans la gestion de ces nouveaux codes et le plantage au reboot suivant pend au nez.
-- Benoît
Avec des fumeurs c'est difficile de s'arrêter. Avec des branleurs, là, par contre, c'est difficile de continuer.
