1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Le noyau




Partons maintenant dans une direction tout à fait opposée, et plongeons dans le cœur de l'OS. A l'occasion, on reviendra aussi à des niveaux plus élevés. Mais là, c'est le moment du noyau.

Il y a eu comme une controverse à partir de l'été 2006 à propos du noyau de Mac OS X, largement entretenue (comme c'est généralement le cas) par un manque d'information. Pour simplifier, Apple n'allait pas livrer le code source de son noyau X86, nouveau à l'époque (comme il l'avait fait pour tous les précédents noyaux), et ne dirait pas pourquoi. Beaucoup d'hypothèses ont vu le jour pour remplir le vide. Bien sûr, j'avais ma propre théorie de prédilection.

La raison la plus logique pour laquelle je peux imaginer le refus d'Apple (jusqu'à présent) de diffuser le code source de la version x86 du noyau de Mac OS X est que le noyau qui est livré aujourd'hui dans les versions x86 de Mac OS X Tiger est une impasse dans le développement, qui pour cette raison, ne vaut pas l'effort de le polir et de le publier.

Vraisemblablement, tout le travail important sous Mac OS X, le noyau et autre chose, est depuis longtemps focalisé sur Léopard. Imaginez maintenant que le noyau de Léopard s'est écarté de façon significative de celui de Tiger. Cela peut être un nouveau noyau, entièrement, ou il peut comporter des modifications significatives pour permettre la virtualisation plus facilement, ou quelque chose entre les deux. Apple semble cacher ses cartes sur sa poitrine jusqu'à la WWDC. En même temps, livrer la source d'une incarnation condamnée du noyau de Tiger, ne serait pas dans la lignée d'une décision cruciale.

J'avais même quelques idées folles sur ce qui, en fait, pouvait remplacer le noyau Mac/BSD existant, des idées qui ne reposaient malheureusement pas sur un examen approfondi. Mais comme d'habitude, j'ai été assez habile (ou couard) pour borner mes suppositions.

Je serais très surpris s'il n'y a pas à la WWDC une annonce importante relative à la technologie du noyau. Cela dit, je ne vois aucun besoin urgent de manœuvres douteuses sur le noyau de Léopard, plus importantes que les améliorations qui sont arrivées avec Tiger. Peut-être que pas d'annonce spectaculaire serait la meilleure solution.

La WWDC est arrivée et s'est achevée (et encore une autre fois), et il n'y eut aucune annonce majeure sur le noyau. Le noyau de Léopard contient en fait plus "du même genre d'améliorations" que nous avons observées pendant l'existence de Mac OS X, et ce n'est pas une mauvaises chose du tout. (Je vais devoir réfréner mes rèves jusqu'à Mac OS X 11.0, je suppose).

Un bonne partie de la folle rumeur à propos du noyau vient de l'idée que Mac OS X est peu performant au niveau du noyau à cause de certains choix de conception fondamentaux. Cela relève d'idées reçues très anciennes, associés à une théorie informatique saine (mais souvent mal appliquée) et à une accumulation prévisible de Benchmarks douteux.

Comme d'habitude, la vérité est beaucoup moins dramatique. L'équipe en charge du cœur du système, chez Apple est, comme on peut s'y attendre, l'opposé complet de l'équipe de conception graphique. En particulier, les ingénieurs du noyau chez Apple sont pragmatiques, précautionneux, et avisés. Ce sont aussi des hommes cependant - si vous les piquez, ne saignent-ils pas aussi ?- ce qui peut expliquer qu'ils passent du temps, à la WWDC, à détailler la philosophie qui est derrière le processus de développement du noyau de Mac OS X.

L'attention d'Apple se porte sur les performances d'ensemble du système, pas sur des micro-benchmarks. Le travail de l'équipe du noyau est de faire que le logiciel apparaisse comme bon au plus haut niveau. Si l'amélioration de la performance d'un facteur dix d'un détail minime du noyau ne fournit pas une amélioration de performance mesurable pour une tâche ou une caractéristique visible par l'utilisateur, ne n'est pas une utilisation efficace de temps de développement, la peste soit de la fierté qu'on peut tirer du benchmark.

Cela ne veut pas dire que l'équipe du noyau chez Apple n'est pas compétitive. Mais quand il s'agit de benchmarks consacrés au noyau il y a un avantage naturel au fait-maison : Linux a tendance à bien se comporter sur LM Bench, Solaris réussit bien avec libmicro et ainsi de suite. Ce n'est pas étonnant : le choix du banc d'essai détermine où est faite l'optimisation. La décision d'Apple de mesurer la performance du noyau au plus haut niveau, en observant le comportement des applications elles-mêmes, tournant sous un OS complet impose quels aspects du noyau reçoivent le plus d'attention.

Dans Mac OS X en général, et dans Léopard en particulier, les améliorations apportées au séquencement et aux attentes sont importantes. Il y a une grosse différence entre être "rapide" et être "réactif", et l'objectif d'Apple, c'est ce dernier. Voici quelques exemples tirés du noyau de Léopard. (Pour les détails de bas étage, il y a le code source, ou il y aura, quand Apple aura mis à jour son site).

Exemples d'améliorations du noyau

Le noyau de Léopard est meilleur pour le séquencement des processus sur les CPUs, évoluant d'une seule queue linéaire de processus en une queue hiérarchique qui s'adapte mieux au matériel actuel (c'est à dire deux chips séparés, chacun avec deux cœurs de CPU). Déplacer un processus d'un CPU à un autre est mauvais pour les performances ; les caches internes n'ont pas l'opportunité de se remplir. Mais des cœurs multiples sur un même chip partagent souvent les mêmes caches. Une hiérarchie de queues de processus dans le noyau, créée à partir de cette connaissance permet de bien meilleurs choix de séquencement.

Le système de mémoire virtuelle de Léopard excelle à déterminer quelles portions de la mémoire sont effectivement utilisées par votre application à un moment donné, et quelles sont celles qu'on peut sans danger basculer sur le disque. Quand le moment est venu de basculer sur le disque, Léopard va (en fin de compte) allouer dynamiquement des fichiers d'échange, ce qui veut dire que vous devriez récupérer un peu d'espace disque quand la pression sur la mémoire s'atténue.

Les limites des ressources, le poison de mon existence sous Tiger et avant, deviennent dynamiques quand c'est possible sous Léopard. Ce sont des choses telles que le nombre de fichiers ouverts ou de processus par utilisateur, et d'autres. Si vous n'avez jamais été confronté(e) à ces limites, considérez vous comme heureux ; un tas de choses s'arrête de fonctionner d'une très vilaine manière quand, par exemple, vous ne pouvez pas ouvrir plus de fichiers.

Je dépasse couramment ces limites sous Tiger, et j'ai souvent été obligé de prendre des mesures héroïques pour les augmenter. Quelques-une des valeurs par défaut ont aussi été augmentées sous Léopard (par exemple, le nombre maximum de processus par défaut par utilisateur est passé de 100 à 266. Je vais encore garder le mien au dessus de 2000, merci bien). Et pour faire bonne mesure, il y a même quelques nouvelles limites sur des ressources préalablement illimitées, comme les tailles de mémoire résidente ou nécessairement en RAM (wired).

Le noyau de Léopard a un nouveau système de bac de sable qui contraint certains processus à tourner dans leur propre environnement, isolé et limité, pour des raisons de sécurité. L'implantation par Apple se base sur le contrôle d'accès obligatoire, (encore un autre acronyme "MAC" qui ne veut pas dire Macintosh). Ces bacs de sable sont définis dans le style Unix standard par de simples fichiers texte (des exemples dans /usr/share/sandbox), et sont appliqués dans Léopard à de nombreux services du système, notamment Bonjour, QuickLook, Spotlight, NTP, et bien d'autres.

DTrace

Peut-être la modification la plus significative dans le noyau de Léopard est-elle l'addition de DTrace. Dtrace a été développé par Sun et est en Open source. L'équipe de Core OS chez Apple a poursuivi sa lancée pour identifier et adopter avec discernement les projets open source les plus racés, et a terminé le travail important consistant à porter DTrace de l'environnement Solaris au noyau Mac OS X. DTrace résout un vieux problème de développement du noyau, et le fait d'une manière tellement imaginative que cela crée de nouvelles occasions pour Apple d'aider tous les programmeurs, et pas seulement les bidouilleurs du noyau.

Pour comprendre comment DTace aide les développeurs du noyau, prenez le scénario suivant. Disons que vous êtes développeur et que vous travaillez sur un aspect donné de la création de processus dans le noyau. Pour vous aider pendant ce développement, vous aimeriez avoir une forme de notification à chaque fois qu'un nouveau processus est créé. Ainsi, vous trouvez la fonction dans le noyau, et vous ajoutez un peu de votre propre code au début de la fonction, qui envoie une information dans un fichier log. Après, vous recompilez votre noyau, vous redémarrez, et continuez à travailler.

Malheureusement, vous avez imposé au moins trois choses en utilisant cette technique : 1) Le fait que vous voulez une information de débogage, 2) la localisation de cette demande, 3) et le mécanisme du rapport. En plus, il est vraisemblable que vous voudrez des morceaux de code de débogage similaires à d'autres endroits du noyau par la suite, et il est peu vraisemblable que vous aurez besoin de tous ces codes actifs en même temps.

Alors, étant le bon petit programmeur que vous êtes, vous en arrivez à une solution plus générale. A chaque endroit où du code de débogage peut être utile, vous enveloppez le code dans une expression conditionnelle qui demande "ce bout de débogage doit-il être activé maintenant ?"

Cela semble une bonne solution, jusqu'au moment où vous avez rempli le noyau de ces bouts de code. Rappelez-vous que par nature, le noyau doit contenir du code qui s'exécute très vite et très souvent. Un tout petit test, pour voir si un morceau de code de débogage doit être activé peut ne prendre qu'une milli-seconde, mais si la routine entière était exécutée en dix milli-secondes avant que vous n'ajoutiez ce test, vous avez augmenté le temps d'exécution d'une façon notable. Et si cette routine est appelée plusieurs milliers de fois par seconde, vous allez dilapider un temps qui finit par compter. Maintenant, multipliez-le par des centaines ou des milliers de sondes dans le noyau, et il devient évident que tous ces tests ne peuvent pas être conservés dans le produit fini.

La solution évidente est de convertir ces test de débogage depuis des conditions qui sont évaluée à l'exécution, à un code compilé conditionnellement. Quand le débogage est demandé, pendant le processus de construction du noyau, une partie ou la totalité du code de débogage est incorporée dans le produit. Mais si le débogage est désactivé pour le produit fini, le code de débogage est entièrement absent du noyau.

Bien que j'aie beaucoup simplifié les choses, c'est là la substance des sondes de débogage traditionnelles pour le noyau. Vous travaillez avec une "version spéciale de débogage", qui peut être lente, mais contient tous les diagnostics dont vous avez besoin pour le développement. Quand vous avez besoin de rajouter, de valider ou d'invalider un morceau de code de débogage, vous recompilez et redémarrez. Quand vous êtes content(e), vous compilez une version de production optimisée du noyau, qui ne contient aucun de ces codes de débogage.

C'est dans cet environnement qu'intervient DTrace, qui propose cette combinaison apparamment impossible de caractéristiques :
Pas de recompilation nécessaire. Validez ou invalidez les sondes de débogage en temps réel, dans le noyau en fonctionnement.
Un surcoût proche de zéro quand il n'est pas utilisé. L'impact du code de débogage invalidé est si petit que tout ce code peut être laissé dans le produit fini.

Les programmeurs qui lisent ceci seront pardonnés de s'être détournés un peu de l'odeur du code auto-modificateur, mais je conseille seulement de fermer les yeux, et de penser à l'Angleterre. En fin de compte, ça marche effectivement, et ça marche bien.

DTrace utilise son propre langage simplifié appelé "D" (non, pas celui-là), qui sert à définit les sondes. Voici un exemple qui imprime une notification à chaque fois qu'un nouveau processus est créé.
listing

La sortie ressemble à cela :
listing

En voilà une un peu plus compliquée. Elle attend la commande ls pour lancer l'appel système stat(), puis trace l'exécution de cet apple à travers le noyau.
listing

Et voici la sortie (abrégée)
listing

En fonctionnement, ce ne peut être différencié de la magie. Vous écrivez ces petits scripts de texte, avec ces lignes séparées, en utilisant ce langage bizarrement proche du C, et vous gagnez fondamentalement un droit complet pour tâter le noyau. (De toute façon, il vous faut être root pour exécuter DTrace, pour des raisons évidentes).

Le langage D n'autorise pas les branchements, les fonctions ou les boucles -une bonne chose, parce que la création accidentelle d'une boucle infinie ou d'une récursion dans le noyau pourrait bien n'être pas rattrapée par un petit morceau de texte en script. Vous ne pouvez pas non plus utiliser DTrace pour modifier la mémoire du noyau ou les registres du CPU, ou pour appeler des fonctions arbitraires.

Mais dans son domaine limité, D est encore tout à fait puissant. Il accepte les types de données de C/C++ les plus courants, les agrégats,les variables locales, et la cohorte des conventions de style shell/awk : des arguments de scripts en $1..$N, les blocks BEGIN..END, etc...Il dispose même d'un support natif pour des histogrammes attractifs. Il est très facile à utiliser, notamment par comparaison avec la recompilation du noyau et le redémarrage.

Et rappelez-vous, ceci fonctionne sur une bonne vieille copie utilisateur de Léopard, pas sur un exécutable spécial. DTrace est inclus dans tous les systèmes Léopard ; ce n'est pas une installation optionnelle. Cela signifie que les développeurs peuvent compter sur le fait que leurs utilisateurs en disposent. Et comme les scripts DTrace sont de simples fichiers texte, déboguer un problème épineux par courriel est devenu tout d'un coup un millier de fois plus facile.

(Les kernels de débogage qui contiennent un ensemble complet de symboles et de méta-data sont encore utiles. DTrace ne les remplace pas. Ce qu'il procure, c'est un niveau jamais atteint de flexibilité au dessus d'eux - une flexibilité qui subsiste même dans la version normale du noyau).

XRay/Instruments

Xray Instruments

Installez les outils de développement, et vous récupérez une application graphique ressemblant à Garage Band pour utiliser les instruments de débogage (vous avez compris ?) sur des applications particulières ou sur le système entier. Cette application fut appelée XRay pendant la plus grande partie du développement, ce qui explique son icône. Elle s'appelle maintenant Instruments, pour des raisons qui ont sans doute à voir avec des juristes. Pardonnez-moi, je vais continuer à parler de Xray dans le reste de ce compte-rendu.

Sans surprise, beaucoup des instruments les plus puissants reposent sur DTrace. Il y a même une interface graphique pour créer des instruments personnalisés basés sur DTrace, plus la possibilité d'enregistrer et de rejouer des séries d'actions. Hum, des tests de performance automatisés basés sur un outil graphique.

DTrace et Xray suscitent de bonnes questions : combien de fichiers mon application ouvre-t-elle au démarrage ? Combien de fois j'appelle une fonction donnée ? Comment évolue l'utilisation de mémoire de mon application dans le temps ? DTrace et Xray permettent de répondre à ces questions, auparavant intimidantes, d'une façon presque triviale, et (oserai-je le dire ?) amusante. Je ne peux pas imaginer un développeur Mac voyant Xray, et instantanément ne pas avoir envie de l'appliquer à son application.

Toute cette puissance nouvellement découverte ne peut que faciliter des applications meilleures, plus rapides et plus stables, des développeurs tierces aussi bien que de la part d'Apple. Et tout cela grâce à un framework de débogage de bas niveau du noyau, peu connu, open source, venu de Sun.

L'état du noyau

Avec Tiger, Apple avait fini par réaliser la transition depuis les racines de NeXT jusqu'au futur de Mac OS X en consolidant les API du noyau, et en proposant un chemin clair pour aller de l'avant. Léopard a fait le premier grand pas sur ce chemin. L'addition de DTrace est la modification la plus importante. C'est une caractéristique entièrement nouvelle, et elle ne fut pas créée avec le noyau de Mac OS X en vue. DTrace va aussi avoir l'impact le plus important sur le processus de développement, et par extension, sur la nature et la qualité des applications disponibles auprès des usagers.

Le reste des modifications est du type "un peu plus de la même chose", et c'est bien : des optimisations de performance, des améliorations de changement d'échelle, une meilleure conformité aux standards, tout cela en doses convenablement modérées. L'addition de DTrace a dû aider un peu dans le reste du développement de Léopard, mais cela a pris du temps pour que DTrace se mette en phase avec Mac OS X. La récompense viendra avec la prochaine version de l'OS, qui aura passé tout son temps de développement dans l'ère post DTrace.