Dans un cas ou dans l'autre, cela serait fort logique de la part d'Apple, et en rien réprimendable.

Je ne comprends pas le rapport du titre avec son contenu :x

Si j'ai bien compris il n'est pas possible d'étudier le fonctionnement de certaines applications d'Apple avec les outils fournis, et tant mieux je ne vois pas en quoi ça regarde les autres, les logiciels apple ne sont pas opensource

Si c'est Opensource, on doit pouvoir récupérer les sources pour les recomplier, enfin essayer, et avoir la version complète, non ?

En fait l'Application Instrument est l'integration par Apple de l'application Open Source Dtrace. En gros c'est une application qui a la base permet de 'poser des sondes' dans les parties du systeme pour voir leur comportement. cela permet ainsi a un developpeur de voir comment reagissent les ressources du systeme lors de l'execution de son application. Ce qui est reprocher a Apple c'est de ne pas donner la possibilite de surveiller le comportement de ses applications. En l'occurrence iTunes.
En substance Apple dit je vous fourni un outil pour optimiser vos applis, pour les miennes c'est mon probleme pas le votre.

Dans mon message precedent, dans integration par Apple il faut lire integration d'une interface graphique par Apple.

Merci pour ces explications Manu, c'est très clair

expliquons le soucis :

dtrace sert à surveiller et analyser l'usage de mac os X par les logiciels
dtrace permet à un développeur de logiciels de voir l'impact de chaque appel système (appeler une fonctionnalité d'os X en gros) par votre logiciel sur le fonctionnement de l'ordinateur

Par exemple: on peut voir où le programme passe la plupart de son temps, et étudier si on peut diminuer ce temps , voir ne pas en passer du tout ou si c'est naturel.
Par exemple, si on voit qu'un logiciel passe 20s toutes les heures à surveiller le contenu de chaque dossier de l'utilisateur, on va chercher à ne plus le faire si on peut s'en passer.

bref dtrace est un outil formidable pour voir ce que fait réellement le logiciel avec os X. il permet de détecter là où on perd du temps et les endroits critiques (blocage de ressource) du programme.

bien, c'est la théorie
mais dans la réalité, votre logiciel ne fonctionne pas tout seul sur un macintosh infini
votre logiciel est en compétition avec les autres programmes, et même aussi les sous-composants d'os X (time machine, window server, finder, spotlight indexeur, etc)

que valent un retour d'activité si vous ne pouvez pas voir celui du reste du système ?
peut être que le programme perd du temps sur une tâche parce que le noyau d'os x avait autre chose à faire (répondre aux exigences de adobe illustrator ou une acquisition de signal de donnée qui exige que le noyau traite cela PRi-O-RI-TAI-RE-MENT.

dtrace vous permet de suivre l'interaction entre votre logiciel et le noyau. en détails

du coup donc, si des logiciels sont omis des retours de dtrace, ils deviennent une zone d'ombre.

ptet ben que le bug est dû à itunes , ptet ben que non, mystèèèère...

alors évidemment, nul ne veut chercher à optimiser itunes (c'est le boulot d'apple), mais comment pouvez vous être sur des résultats, si une partie est censurée ?

la solution ? ne pas lancer itunes , ha! mais soyons réaliste, en situation réelle, y a itunes.

tiens, d'ailleurs, quand je disais qu'on ne peut pas se contenter de tester son programme tout seul dans un coin pour le tester, c'est pour cela que les éditeurs, lors de plantages, vous demandent de leur dire quels logiciels étaient en fonctionnement en même temps. pour voir si le bug est lié à l'usage de ressources par d'autres logiciels : recréer les conditions réelles du bug.

si on omet la théorie du complot "anti-opensource bouh les méchants", c'est vrai que les exigences de DRM par les ayants droits est la raison la plus plausible. je ne pense pas qu'on puisse avoir de certitudes sans être ingénieur apple. (ou alors un expert dtrace et drm saura dire si c'est crédible de deviner le fonctionnement d'un drm via des sondes dtrace)

[quote]Il regrette par conséquent qu'Apple ne joue pas totalement le jeu.[/quote]
non, ce qu'il regrette c'est que les résultats de dtrace sur le système dans son ensemble ne sont plus fiable à cause de ce bridage.

ha mais c'est tres simple de deconvoluerce qu'utilise ton programme et ce que le systeme utilise: il te suffit de tester ton programme plusieurs fois (le code a pas changer donc il consommera toujours autant de ressource, le systeme lui consomera toujours les ressources dont il aura besoin, ce qui est variable au cours du temps).
Considere les ressources système comme un bruit de fond. apres tout ton programme est ergodique normalement

hoolaa, Elende, ici on ne joue plus du tout dans ma cour habituelle (celle de la maternelle ^^ ) , d'abord un, mes restes de math sont très fragmentaires et je n'ai pas étudié la thermodynamique (!) donc je ne suis pas sur de comprendre l'hypothèse ergodique et son application à notre cas.

oui, on peut considérer l'activité système comme un bruit de fond. cela je le conçois bien et les sondes dtrace c'est effectivement une mesure d'un signal

mais une logiciel utilisateur habituel je ne pense pas qu'on puisse le voir comme une fonction au comportement toujours similaire

peut être l'utilisateur va ouvrir avec un fichier corrompu, peut être l'utilisateur n'ouvre jamais certaines fonctions du logiciel,etc.

son comportement ne pouvait pas être toujours le même et ne pouvant pas garantir que l'application va passer par tous les états (et dans le même ordre) du programme à chaque session de travail, je ne suis pas sur que cette théorie mathématique prenne véritablement en compte la nature de ce qu'est un logiciel
utilisateur

et dire que donc le programme passe par tout ses états au bout d'un temps qu'on pourrait théoriser, je doute. mais bon, je ne suis pas théoricien.

bref, un logiciel linéaire (un script par exemple), ok, je pense saisir , mais avec un logiciel, tel heu.. Omnigraffle, je ne pense pas que cela soit réaliste.

hum !