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

Détails internes




Cette section de pot pourri me donne l'occasion d'aborder brièvement des caractéristiques intéressantes, qui ne justifient pas leur propre section, ou souvent que le manque de temps m'a empêché de développer en sections complètes. C'est la première fois que je consacre aux détails internes leur propre pot pourri, pour les séparer du pot pourri qui va suivre sur les caractéristiques visibles par l'utilisateur. Dit d'une autre manière, c'est un pot pourri sans recopies d'écran.


Les méta-données en action

Léopard est la première livraison de Mac OS X à tirer effectivement avantage des APIs d'attributs étendus ajoutées à Tiger. Confrontée au problème qui nécessite le stockage d'une certaine information pour un fichier donné, ou un répertoire, Apple s'est finalement résolue à utiliser des méta-données dans le système de fichiers (ouf !) . On les retrouve partout dans Léopard. Considérez seulement ces noms d'attributs étendus :
com.apple.metadata:kMDItemFinderComment Des commentaires dans le Finder en méta-données. (Elles sont encore stockées aussi dans les fichiers .DS_Store sans doute pour assurer la compatibilité avec les systèmes pré-Léopard).
com.apple.quarantine Marquer des fichiers téléchargés depuis Internet comme potentiellement dangereux, se rappeler de l'application qui les a téléchargés, entre autres choses.
com.apple.backupd.SnapshotVolumeLastFSEventID L'un, parmi une suite complète, des attributs étendus utilisés par une certaine caractéristique de sauvegarde décrite par la suite

C'est suffisant pour m'arracher le cri de "Alleluia !" Comment ces choses-là sont-elles utiles ? Imaginez seulement les contorsions stupides qu'Apple aurait dû faire dans son environnement pré-méta-données pour stocker et récupérer cette information, chaque application allant dans sa propre direction, avec une implantation personnalisée. Tant d'efforts gâchés, tant de bogues uniques. C'est fini ! Les attributs étendus fournissent un outil d'usage général pour faire les même choses, disponibles sans effort, et dépourvus de bogues.

Léopard dispose même d'une commande CLI pour afficher et modifier les attributs étendus. Les lecteurs se rapplelleront peut-être un utilitaire équivalent, appelé xattr créé par Marquis Logan pour mon compte-rendu sur Tiger. L'utilitaire d'Apple a le même nom, mais des options légèrement différentes.

D'autre commandes sous Léopard savent aussi prendre en compte les attributs étendus. Par exemple, la commande ls affiche maintenant un caractère "@" après la chaîne des permissions pour chaque fichier qui a des attributs étendus. Parcourir le système l Léopard avec les commandes ls et xattr révèle à quel point Apple a pris les méta-données à cœur. Le moment est venu.

Core Text

Mac OS X a finalement une seule API officielle pour dessiner et rendre du texte standand : Core Text. (A ma connaissance, cette technologie "Core" ne dispose pas de sa propre icône en forme de sphère bien léchée). Core Text remplace l'ensembles des APIs de texte de Mac OS X Tiger et des versions précédentes, largement héritées de Mac OS Classique : ATSUI, MLTE, et Quick Draw Text.

Core Text a une API plus propre, elle est plus rapide, elle est disponible en 64 bits (yada, yada). J'en parle ici pour deux raisons. 1) D'abord, c'est intéressant parce que Core Text existait dans Tiger en tant qu'API privée. Elle était utilisée par les propres applications d'Apple comme une sorte de banc d'essai pour le framework. Léopard est sa sortie officielle, maintenant qu'il a été correctement mis au point.

Cela rappelle la situation de FSEvents, mais dans ce cas, Apple a décidé que l'API privée qui avait été proposés dans Tiger /dev/fsevent n'était pas adaptée à un usage public, et qu'il fallait une autre solution. Peut être que /dev/fsevent, à la différence de Core Text n'a jamais été destinée à être rendue publique, mais peut-être que ce n'est qu'une vision après coup. Quoi qu'il en soit, ayez l'œil sur les frameworks privés de Léopard, qui pourraient se retrouver publiés dans 10.6.

2) Ensuite, Core Text est un indicateur de l'extrême jeunesse, en termes relatifs, de Mac OS X en tant que plate-forme. Mac Os X est vraiment une plate-forme. Voilà Léopard, visiblement un produit mature dans sa sixième livraison majeure, et qui maintenant reçoit une API de rendu de texte standard ? Aussi évolué que Mac OS X puisse sembler, c'était en fait un assemblage hétéroclite de technologies dès sa naissance : un peu d'Unix BSD ici, un peu de NeXT là, et tout un seau de Mac OS classic répandu par dessus. Cela va prendre longtemps pour démêler tout ça. Léopard fait quelques pas importants vers le futur en supprimant plusieurs technologies anciennes et en sacrant leurs successeurs.


La signature de code

Léopard supporte des applications avec une signature chiffrée. Le sujet retentit comme une sonnette d'alarme pour certains. L'initiative controversée de Microsoft Palladium a sensibilisé le public il y a plusieurs années, quand Microsoft a mal évalué le marché, et fini par laisser entrevoir un futur hostile de contrôle d'airain dans les entreprises, plutôt que l'utopie sécuritaire qu'ils essayaient de placer. De nos jours, il est difficile pour certains de ne pas considérer de telles tentatives comme des prises de pouvoir opportunistes, déguisées sous des caractéristiques de "sécurité".

La première chose à comprendre à propos de la signature de code dans Léopard, c'est qu'il n'est pas présenté comme, et n'est pas capable, de quelque chose d'aussi ambitieux. Il ne va pas donner à Apple (ou à qui que soit d'autre) un contrôle complet sur votre système, et il n'est pas fait pour fournir une sécurité impénétrable.

Voilà ce qu'il fait, en fait. La signature de code associe une identité chiffrée vérifiable à une collection de code, et s'assure que toute modification à ce code est détectée. Aucune garantie n'est fournie sur les parties en présence. Par exemple, si vous téléchargez quelque chose qui se réclame de Acme Inc, vous ne pouvez rien en déduire d'autre qu'elle vient de la même entité qui se réclame de Acme Inc, la dernière fois que vous avez téléchargé quelque chose sur leur site.

Cet exemple illustre l'application la plus utile de cette technologie du point de vue de l'utilisateur. Quand il met à jour une application actuellement, l'utilisateur est souvent invité à re-vérifier que cette application est autorisée à utiliser l'accès au trousseau pour récuperer les noms d'utilisateur et les mots de passe. Cela semble une bonne mesure de sécurité, mais ce qu'elle fait en fait, c'est d'habituer les utilisateurs de Macs à cliquer aveuglément sur "Toujours autoriser" à chaque fois que le dialogue apparaît. Et en fait, que peut faire un utilisateur moyen ; lancer l'exécutable par l'intermédiaire d'un désassembleur, et vérifier manuellement que le code est sûr ?

Une application signée, à l'inverse, peut prouver mathématiquement que c'est bien une nouvelle version de la même application venant du même vendeur à laquelle vous avez fait confiance auparavant. Le résultat, c'est la fin des boîtes de dialogue vous demandant de confirmer un choix dont vous n'avez aucun moyen raisonnable de vérifier la sûreté.

A la fin, cela revient quand même à faire confiance. Ou bien vous avez confiance dans le logiciel de Acme Inc, ou vous ne l'avez pas. A vous de décider. Des applications signées sont tout aussi capables d'effacer votre disque dur, ou de dérober vos mots de passe que des applications non signées.

Mais à la différence d'un code non signé, une application signée ne peut pas être altérée après son installation. Si une application de Acme Inc fait quelque chose de malsain, vous pouvez être sûr(e) que ce n'est pas parce qu'elle a été détournée par une forme de logiciel malveillant. Exprimé d'une autre façon, du code bien conformé continuera à être bien conformé. Toute tentative de la modifier l'empêchera définitivement de tourner.

Apple a signé toutes les applications livrées avec Léopard. Je m'attends à ce que la plupart des développeurs indépendants de confiance fassent de même en fin de compte.

La signature de code signifie aussi la fin d'une pratique où les applications se modifiaient elles-mêmes (par exemple, sauver des fichiers personnalisés de thèmes dans le paquetage de l'application lui même au lieu de les mettre dans ~/Library/Application Support/MyApp ou un autre emplacement propre à l'utilisateur). Cette pratique a toujours été découragée par Apple, et il y a maintenant une autre raison pour l'éviter

Pour résumer, la signature de code assure :
• un code de sécurité authentifié
• et la vérification de l'identité de l'authentificateur.

Ce que ne fait pas la signature de code :
• fournir des privilèges spéciaux
• protéger contre les bogues
• protéger contre une confiance mal placée
• fournir une copie de protection
• vous asservir à La Matrice

Cela n'est qu'un petit pas vers plus de sécurité, mais il est fait correctement. ASLR

S'agissant de sécurité, Léopard implante aussi le positionnement aléatoire de l'espace d'adressage, ou ASLR (en français). Le nom suffit à expliquer : ASLR déplace le code en mémoire pour rendre plus difficile à des logiciels la prédiction d'une adresse de code donné. Apple a encore beaucoup de travail à faire pour atteindre le degré actuel de paranoïa de Microsoft au sujet de la sécurité, mais jusqu'à présent, Mac OS X n'a pas été confronté aux mêmes pressions de malware qu'a subies Windows. C'est quand même bien de voir Apple prendre une initiative dans ce domaine, plutôt que d'attendre le désastre pour réagir.

LLVM

LLVM signifie Low Level Virtual Machine (machine virtuelle de bas niveau). C'est un projet open source que Apple a pris sous son aile, en rétribuant le développeur principal, et en participant activement à l'amélioration du code. Vous pouvez savoir tout ce que LLVL peut faire sur le site du projet. Mais les explications que vous allez trouver là sont plutôt incompréhensibles si vous n'êtes pas déjà familier(e) avec les les technologies des compilateurs. La meilleure façon de comprendre LLVM est dans son nom : c'est une machine virtuelle (en français), mais une machine qui représente des choses de bas niveau, comme un CPU, plutôt que de les modéliser au niveau du PC entier.

Pourquoi modéliser quelque chose d'aussi primitif ? Qui voudrait écrire du code qui a pour cible un CPU virtuel ? Et bien, les compilateurs, eux mêmes. L'idée est de produire du code dans la représentation intermédiaire (IR) de LLVM (une plate-forme neutre), et LLVM va l'optimiser et le convertir en code natif pour le CPU de votre choix. Cette conversion peut être faite plus tard ; vous produisez du code exécutable, et vous pouvez envoyer le code de la plate-forme neutre tel quel, et laisser LLVM le compiler à la volée (JIT).

Pourquoi s'encombrer de cet intermédiaire LLVM ? Pourquoi ne pas laisser le compilateur créer de lui-même du code natif ? C'est ce que font la plupart des compilateurs. Malheureusement, il le font avec des degrés divers de qualité. L'ambition de LLVM est de fournir un ensemble de composantes modulaires du compilateur que tout le monde peut utiliser, pour concentrer les efforts d'optimisation actuellement disséminés sur beaucoup de compilateurs différents, en un seul projet ; d'où l'utilisation d'une plate-forme neutre et d'une représentation intermédiaire.

Pensez-y comme à un gros entonnoir : vous enfournez par le haut toutes sortes de code que vous pouvez imaginer, et cela finit comme une Représentation Intermédiaire (IR) LLVM. Puis LLVM optimise tous les embêtements en utilisant tous les trucs connus. Finalement, LLVM fournit un code natif à partir de sa Représentation Intermédiaire. La concentration de l'effort de développement est évidente : un optimiseur agissant sur un seul format (LLVM IR), et un seul générateur de code natif pour chaque CPU cible. A mesure que LLVM va s'améliorer et devenir plus rapide, tout compilateur individuel qui utilise LLVM va aussi devenir meilleur.

Voilà l'idée. La réalité, c'est qu'il va falloir longtemps pour convaincre le monde des compilateurs de l'intérêt de cette approche. Apple, cependant, est déjà dans la course. Dans Léopard, LLVM est utilisé dans ce que vous pourriez considérer comme un endroit étrange : Open GL.

Quand une carte vidéo ne supporte pas une caractéristique donnée (par exemple une opération d'ombrage sur un pixel ou sur un vertex) matériellement, il faut retomber sur du logiciel pour l'obtenir. Les GPUs programmables modernes proposent un défi particulier. Les applications Open GL n'appellent plus seulement des fonctions fixes, elles peuvent aussi passer au GPU des petits programmes entiers pour qu'il les exécute.

Avant LLVM, Apple écrivait des alternatives logicielles en utilisant son compilateur à la volée pour les GPUs programmables. Elle écrivait du code natif pour chaque opération primitive (par exemple un produit scalaire. Ces morceaux de code doivent être réunis à l'exécution pour produire l'équivalent CPU du mini programme censé aller avec le GPU.

Cette approche limite sérieusement la portée des optimisations possibles. Toute transformation qui s'étend sur plus d'une opération primitive est très difficile, et ne permet que des optimisations simples et limitées dans chaque primitive.

Jusqu'à présent, Apple se contentait de sa compilation à la volée quand elle n'avait pour cible que des CPU Power PC de 32 bits. Mais avec le Power PC 64 bits, et plus tard, avec les CPUs Intel 32 et 64 bits qui ont rejoint la plateforme, la mise à jour de la compilation à la volée pour ces nouvelles architectures (et des caractéristiques telles que SSE, SSE2, SSE3...) a commencé à devenir compliquée.

Un compilateur maison, avec de faibles possibilités d'optimisation, et un nombre toujours plus grand de cibles CPU ? LLVM est venu à l'aide. Dans Léopard, chaque primitive est contenue dans une bibliothèque de fichiers en byte code LLVM (cherchez des fichiers avec une extension .bc). Mélanger des appels différents à ces bibliothèques de byte code, et les compiler à la volée en un seul morceau de code natif ? Pas de problème. C'est ce pour quoi a été conçu LLVM.

On peut supposer que LLVM consolide Open GL, en fonctionnant plusieurs centaines de fois plus vite que la vieille compilation maison à la volée d'Apple pour certaines opérations que le vieux système ne pouvait même pas traîter à la volée, mais seulement interpréter. Le gain le plus important tient peut-être dans le fait que le groupe Open GL d'Apple n'est plus obligé de maintenir son propre compilateur à la volée. La meilleure forme de code, c'est pas de code du tout.

Ne soyez pas abusé(e) pas son utilisation limitée dans Léopard ; Apple a des plans grandioses pour LLVM. A quel point ? Changer les boyaux du compilateur gcc que Mac OS X utilise, et le remplacer par les équivalents en LLVM ? Le projet est bien parti. Pas assez ambitieux ? Pourquoi ne pas se débarrasser complètement de gcc, et le remplacer par un compilateur complètement nouveau, basé sur LLVM, mais compatible gcc ? Ce projet s'appelle Clang, et il a déjà fourni des résultats d'une performance impressionnante. Notamment, sa capacité à faire de la compilation incrémentale rapide, et à fournir une collection beaucoup plus riche de méta-données est un énorme bénéfice pour des IDEs graphiques tels que Xcode.

Je sais que cette sous-section sur LLVM est une digression, mais même si il n'est utilisé que de façon limitée dans Léopard, LLVM est tout à fait important pour le futur de Mac OS X. En fait, il pourrait être aussi important dès maintenant pour l'iPhone ou d'autres plate-formes OS X.

Je ne sais pas bien comment l'iPhone gère tous les effets visuels utilisés dans son interface, mais il n'est pas irraisonnable d'imaginer que Core Animation, Open GL, et des substituts logiciels à base de LLVM sont essentiels pour obtenir toute cette activité, sur une plate-forme avec des GPUs et des CPUs de bas de gamme. Et puis, ai-je dit qu'Apple a récemment fait un travail important sur une version ARM de LLVM ? Vous savez, ARM, le CPU utilisé dans l'iPhone. Hé oui, les morceaux s'encastrent bien.

Quoi qu'il en soit, merci pour votre indulgence. Si vous voulez en savoir plus sur les derniers développements de LLVM, regardez la vidéo de présentation de LLVM sur Google par Chris Lattner, le développeur principal de LLVM, appointé par Apple.

Objective-C

J'ai mentionné brièvement le nouvel exécutif Objective C dans la section 64 bits. Cela fait partie de la révision de grande ampleur du langage, appelée Objective-C 2.0. La promotion de cette version de base est appropriée, parce que les possibilités d'Objective-C s'articulent beaucoup sur la bibliothèque exécutive comme noyau. Cette bibliothèque fournit l'introspection et les extensions de classes, la méthode dispatch, et dans la version 2, une gestion de la mémoire aussi.

C'est sûr, la nouvelle la plus importante à propos du nouvel Objective-C 2.0 est qu'il supporte le ramasse miettes (garbage collection). C'est une caractéristique optionnelle, et une même base de code peut être compilée avec ou sans le support du ramasse miettes. Quand il est validé, tous les appels manuels de gestion de la mémoire sont simplement ignorés. C'est comme ça que sont écrites toutes les bibliothèques Objective-C de Léopard : elles peuvent fonctionner avec le ramasse miettes validé ou invalidé.

Pour les développeurs, Objective-C 2.0 inclut plusieurs caractéristiques qui légalisent des expressions courantes. Par exemple, il y a maintenant le support incorporé pour les méthodes simples accessor et mutator aux propriétés des objets. L'écriture de méthodes de ce genre est ennuyeuse et sujette à des erreurs. Comme les bonnes pratiques sont maintenant bien définies, Apple a simplement rajouté ces propriétés comme des caractéristiques "natives" du langage. J'ai mis natives entre guillemets, parce que cela se ramène à une forme de sucre syntactique, mais un peu de sucre, c'est une bonne chose.

Objective-C 2.0 est un grand pas en avant pour un langage qui n'a pas beaucoup changé dans la dernière décade au moins. Bien que Objective-C soit open source, et soit supporté par le compilateur C GNU, Apple possède effectivement Objective-C comme Microsoft possède C#. Apple est, de loin, l'utilisateur le plus important du langage, et a la plus forte légitimité pour l'améliorer. Objective-C 2.0 est une déclaration de cette propriété, et elle paraît incontestée. Les développeurs, pendant ce temps s'en délectent. Mais mes yeux sont tournés vers le futur.

Au moment de l'introduction de Objective-C 2.0, Apple a fait attention à replacer le changement dans son contexte, déclarant que Objective-C 2.0 "n'est pas n'est pas focalisé sur des changements révolutionnaires dans votre environnement de développement pour atteindre la prochaîne génération des environnement de développement" (j'ai ajouté l'emphase). C'est bel et bon, mais alors, qu'est-ce qui est censé apporter "la prochaîne génération d'environnement de développement" ?

Je m'en suis moqué depuis des années, et la pression ne fait que monter. Quels sont les plans d'Apple pour une transition vers un environnement de développement dynamique, entièrement géré en mémoire ? J'ai proposé un blog en trois parties (1, 2 et 3) là-dessus dès 2005, avec le titre volontairement provocateur "Eviter un Copland 2010". (L'année 2010 se situe probablement quelques année avant le point de crise). Dans ce blog, j'ai exprimé mon agacement en considérant que Objective-C avec le ramasse miettes était une solution inadaptée à long terme. Il semble que Apple est de mon avis, mais qu'il laisse encore le problème sans solution.

Je suis sûr qu'il y a des développeurs Mac en train de lire cela, et qui ne voient aucun problème, ni pour 2010, ni autrement. Je pourrais prendre une autre tangente sur la façon dont les programmeurs semblent toujours penser que le langage qu'ils utilisent sur le moment fournit exactement le bon niveau d'abstraction pour la tâche en cours, où quelque chose de moins dynamique serait considéré comme primitif, et tout ce qui serait plus dynamique vu comme idiot et aventureux, mais je vais vous épargner, et garder ça pour un autre blog.

En même temps, la conclusion concernant Léopard est que Objective-C 2.0 est une bonne chose. Les additions au langage rendent Objective-C plus agréable à utiliser et plus facile à apprendre. Le nouvel exécutif est plus propre, plus rapide, et plus puissant. Le ramasse miettes, s'il devient aussi envahissant qu'il le devrait, va inciter une nouvelle génération de développeurs Mac, à laisser au soin de l'ordinateur une fonction de contrôle supplémentaire. S'il y a une falaise devant, au moins Apple prend-elle de la vitesse, et commence-t-elle à édifier une rampe d'accès. J'espère seulement trouver quelque chose de l'autre côté de l'horizon, quand nous aurons atteint la limite.