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

L'installation




Apple fait savoir que le processus d'installation de Léopard des neiges est "jusqu'à 40 % plus rapide". Les durées d'installation varient considérablement en fonction de la vitesse, du contenu, et de la fragmentation du disque, de la vitesse du lecteur de disque optique, et d'autres choses. Mais l'installation n'intervient qu'une fois, et ce n'est pas quelque chose de très intéressant, à moins que quelque chose n'aille très mal. Toutefois, puisque Apple fait cette promesse, autant la tester.

Pour éliminer autant de variables que possible, j'ai installé à la fois Léopard et Léopard des neiges d'un disque dur sur un autre qui était vide. Il faut noter que cette modification empêche quelques unes des plus importantes optimisations d'installation de Léopard des neiges, qui se concentrent sur la réduction de l'accès aléatoire aux données à partir du disque optique.

Même avec ce désavantage, l'installation de Léopard des neiges a pris environ 20 % de moins de temps que celle de Léopard. C'est loin de la déclaration d'Apple "jusqu'à 45 %", mais voyez ce qui précède (et n'oubliez pas la précaution d'Apple : "jusqu'à"). Les deux versions se sont installées en moins de 30 minutes.

Ce qui est frappant, avec l'installation de Léopard des neiges, c'est avec quelle rapidité le processus d'indexation de Spotlight s'est fait. Là, Léopard des neiges a été 174 % plus rapide, selon mon test. Bien sûr, les temps sont courts 5mn49 contre 3mn30, et encore une fois, une nouvelle installation sur un disque vide n'est pas la norme. Mais l'attente plus courte pour l'indexage de Spotlight vaut d'être notée parce que c'est la première indication que les utilisateurs vont avoir que Léopard des neiges signifie efficacité en raison de sa performance.

Une autre chose notable dans l'installation est ce qui n'est pas installé par défaut : Rosetta, l'outil qui permet aux binaires PowerPC de tourner sur des Macs Intel. Bon, Apple, on a compris. Le Power PC est contraignant et dépourvu de vie. Il repose en paix. Il est passé derrière le rideau, et a rejoint le chœur invisible. Pour Apple, le Power PC est un ex-ISA (un jeu d'instructions révolu).

Mais, ne pas installer Rosetta par défaut ? Cela semble un peu rude, et même grossier. Que va-t-il arriver à tous ceux qui auront fait la mise à jour à Léopard des neiges, et qui vont double-cliquer sur une application dont ils ont oublié depuis longtemps qu'elle était faite pour un Power PC ? D'une façon surprenante, peut-être, voici ce qui arrive :

Installer Rosetta

Rosette : installation automatique pour votre confort

C'est ce que j'ai vu apparaître quand j'ai cherché à lancer Disk Inventory X sur Léopard des neiges, une application dont j'avais oublié depuis longtemps qu'elle était pour PPC seulement. Après avoir cliqué sur le bouton Install, je m'attendais à être pressé de mettre le DVD d'installation. Mais à la place, Léopard des neiges est allé sur Internet, a rapatrié Rosetta depuis le serveur Apple, et l'a installé. Téléchargement de Rosetta

Il n'y a pas eu besoin de redémarrer, et Disk Inventory X s'est chargé sans problème après l'installation de Rosetta. Mac OS X n'a pas fait grand usage de l'approche "installer à la demande" des composants logiciels du système, mais le moyen utilisé pour installer Rosetta semble tout à fait convenable. Quand on clique "Install", une property list XML contenant un vaste catalogue de packages disponibles pour Mac OS X a été téléchargée. Léopard des neiges utilise le même procédé pour installer les pilotes d'imprimantes à la demande, et évite un nouvel accès au DVD d'installation. J'espère que cette technique va être encore plus utilisée dans le futur.

L'empreinte de l'installation

Rosetta mis à part, Léopard des neiges dépose simplement moins de bits sur votre disque. Apple prétend que cela prend "jusqu'à moins de la moitié d'espace disque que la version précédente". Une installation propre par défaut, (incluant les index Spotlight entiers) fait 16,8 Go pour Léopard, et 5,9 Go pour Léopard des neiges.(Incidemment, ces nombre sont tous deux puissances de deux ; voir l'aparté).

------------------------------------------------------
Un Gigabyte ou un autre
Léopard des neiges a un autre tour dans son sac quand il s'agit de l'usage du disque. Le Finder de Léopard des neiges considère que 1 Go est égal à 109 (1 000 000 000 octets), alors que le Finder de Léopard - et notons-le de toutes les versions antérieures- assimile 1 Go à 230 (1 073 741 824 octets). Cela a pour conséquence de faire apparaître votre disque soudain plus grand après l'installation de Léopard des neiges. Par exemple, mon disque de 1 To apparaît dans le Finder de Léopard avec 931,19 Go. Sous Léopard des neiges, il fait 999,86 Go. Comme vous l'avez sans doute deviné, les fabricants de disques durs utilisent le système en puissances de dix. C'est tout à fait désolant, en fait. Bien que je me tienne fermement du côté des défenseurs des puissances de deux, je ne peux pas trop blâmer Apple de vouloir se mettre au niveau du standard de mesure des vendeurs de disques, établi de longue date (mais stupide, pensez-y).
------------------------------------------------------

Léopard des neiges a plusieurs secrets pour perdre du poids. Le premier est évident : l'absence de support du Power PC signifie qu'il n'y a pas de code Power PC dans les exécutables. Rappelez-vous le code binaire maximum dans un exécutable Léopard : 32 bits PowerPC, 64 bits PowerPC, x86, et x86_64. Maintenant, barrez la moitié de ces architectures de la liste. Je vous l'accorde, très peu d'ar_05_06.phppplications dans Léopard utilisent un code 64 bits, mais c'est quand même une réduction de 50 % des exécutables, quelle que soit la façon dont vous comptez.

Bien sûr, tous les fichiers d'un système d'exploitation ne sont pas des exécutables. Il y a les fichiers de données, les images, les fichiers audio, et même un peu de fichiers vidéo. Mais la plupart de ces fichiers non exécutables ont une chose en commun : ils sont normalement stockés dans des formats de fichiers compressés. Les images sont en PNG ou en JPEG, l'audio est en AAC, la vidéo en MPEG-4, et les fichiers de préférences eux-mêmes, et autres property-lists (listes d'attributs) sont maintenant par défaut dans un format binaire compact plutôt qu'en XML.

Dans Léopard des neiges, d'autres formes de fichiers montent dans le wagon de la compression. Pour ne donner qu'un exemple, 97 % des fichiers exécutables de Léopard des neiges sont compressés. Compressés comment ? Regardons un peu : listing

Hé, c'est euh plutôt petit, non ? Est-ce que c'est vraiment un exécutable, ou quoi ? Essayons de tester nos affirmations. listing

Ben quoi ? Qu'est-ce qui se passe ? Eh bien, ce que je ne vous ai pas dit, c'est que les commandes présentées ci-dessus ont été exécutées sur un système Léopard, inspectant un disque Léopard des neiges. En fait, tous les fichiers compressés de Léopard des neiges apparaissent avec 0 octets quand ils sont vus depuis une version de Mac OS X antérieure à Léopard des neiges. (Bien sûr, ils apparaissent et agissent de façon parfaitement normale sous Léopard des neiges).

Alors, où sont les données ? Le petit "@"à la fin de la chaîne des permissions dans le résultat de la commande ls ci-dessus (une caractéristique introduite dans Léopard) fournit un indice. Bien que l'exécutable Mail ait une taille de fichier de zéro, il a en fait quelques attributs étendus : listing

Ah, voilà toutes les données. Mais attendez, c'est dans la ResourceFork (fourche ressources)? N'ont-elles pas été abandonnées depuis environ 8 ans ? Bien sûr, elles l'ont été. Ce dont vous êtes témoins ici, est encore une autre addition au dada favori d'Apple en matière de système de fichiers, HFS +.

A l'aube de Mac OS X, Apple a ajouté la journalisation, les liens symboliques et les liens matériels. Dans Tiger, les attributs étendus et les listes de contre d'accès (ACLs) ont été ajoutés. Dans Léopard, HFS+ a gagné l'adjonction des liens matériels sur les répertoires. Dans Léopard des neiges, HFS + apprend un nouveau tour : la compression par fichier.

La présence de l'attribut com.apple.decmpfs est le premier indice que ce fichier est compressé. Cet attribut est en fait caché de la commande xattr quand on démarre sous Léopard des neiges. Mais vu d'un système Léopard qui n'a aucune connaissance de sa signification particulière, il est révélé en plein jour.

Plus d'information encore est fournie grâce au programme hfsdebug dans le livre Mac OS X Internals du gouru Amit Singh. listing

Et là c'est sûr, comme nous l'avons vu, la fourche ressource contient des données compressées. Mais encore, pourquoi la fourche ressource ? Cela fait partie de l'habile gymnastique usuelle d'Apple pour assurer une compatibilité rétrograde. Un exemple récent dans cette voie est la façon dont les liens matériels sur des répertoires apparaissent - et fonctionnent- comme des aliases vus depuis une version pré-Léopard de Mac OS X.

Dans le cas de la compression dans HFS +, Apple a été incapable (c'est compréhensible) de faire que les anciens systèmes, pré-Léopard des neiges puissent lire et interpréter des donnés compressées, qui sont stockées d'une façon qui n'existait pas quand ces systèmes plus précoces ont été écrits. Mais plutôt que de laisser les applications (et les utilisateurs) qui fonctionnent sur des systèmes antérieurs à 10.6 se battre avec -ou pire, corrompre après modification- le contenu de fichiers qu'on de sait pas identifier comme compressés, Apple a choisi de cacher les données compressées.

Et où le contenu d'un fichier qui peut être gros peut-il être caché de façon que les systèmes pré-Léopard puissent encore copier le fichier sans perdre de données ? Dans la fourche ressources, bien sûr. Le Finder a toujours préservé correctement les métadata spécifiques au Mac, et à la fois les fourches ressources et data, quand il déplace ou duplique des fichiers. Dans Léopard, même les commandes de bas niveau cp et rsync le font. Si bien que, quelque fantomatique que ce soit de voir tous ces fichiers "vides" à 0 Ko quand on regarde un disque Léopard des neiges depuis un système Léopard, le risque de perdre des données est faible même si vous déplacez ou copiez un de ces fichiers.

La fourche ressources n'est pas le seul endroit où Apple a décidé de passer ses données en contrebande. Pour de très petits fichiers hfsdebug montre ceci : listing

Là, les données sont assez petites pour tenir entièrement dans l'attribut étendu bien que sous forme comprimée. Et puis, l'étape ultime :
listing

C'est vrai, voici le contenu d'un fichier entier stocké de façon non comprimée dans un attribut étendu. Dans le cas d'un fichier PkgInfo standard comme celui-ci, ces contenus sont les codes classiques dans Mac OS, en quatre octets, du type et du créateur.
listing

Il y a encore le même préambule "fpmc..." que nous avons vu dans tous les exemples précédents de l'attribut com.apple.decmpfs, mais à la fin, les données attendues apparaissent au grand jour : le code du type "APPL" (application) et le code du créateur "emal" (pour l'application Mail, pertinent comme dans la tradition de Mac OS.)

Vous vous demandez peut-être, puisqu'on est dans la compression de données, comment le fait de stocker 8 octets non compressés, plus un préambule de 17 bytes dans un attribut étendu sauve de l'espace disque ? La réponse tient dans la manière dont HFS + alloue l'espace disque. Quand il stocke de l'information dans une fourche data ou ressource, HFS + alloue l'espace en multiples de la taille du bloc d'allocation du système de fichiers (4 Ko par défaut). Si bien que ces 8 bits prendront un espace minimum de 4096 octets dans la façon traditionnelle de stocker. Quand on alloue de l'espace disque pour des attributs étendus, cependant, la taille du bloc d'allocation n'est pas en cause ; les données sont compactées de façon plus serrée. Au bout du compte, l'espace effectivement gagné en stockant ces 25 octets de données dans un attribut étendu dépasse 4000 octets.

Mais la compression ne sert pas seulement à sauver de l'espace disque. C'est aussi un exemple classique d'utilisation des cycles des CPUs pour diminuer le temps d'attente des entrées/sorties, et améliorer la bande passante. Pendant les dernières décades, la performance des CPUs s'est améliorée (et les ressources de calcul sont devenues plus abondantes -plus là-dessus plus tard), à une cadence beaucoup plus grande que la performance des disques ne s'est accrue. Le temps de positionnement des disques, et les délais de rotation se mesurent encore en millisecondes. En une milliseconde, un CPU à 2 GHz passe par deux millions de cycles. Et puis, il faut prendre en compte le temps effectif de transfert des données.

Je l'accorde, plusieurs niveaux de cache dans le système d'exploitation et le matériel contribuent efficacement à masquer ces délais. Mais tous ces bits doivent bien sortir du disque à un moment ou un autre pour nourrir ces caches. La compression implique que moins de bits doivent être transférés. Etant donnée l'abondance presque comique des ressources CPU sur un Mac moderne multicœurs en utilisation normale, le temps total nécessaire pour transférer une charge compressée depuis le disque et utiliser le CPU pour décompresser son contenu en mémoire sera encore habituellement beaucoup plus faible que le temps que cela prendrait pour transférer des données non compressées.

Cela explique les bénéfices potentiels de performance obtenus en transférant moins de données, mais l'utilisation des attributs étendus pour stocker le contenu des fichiers peut effectivement rendre les choses plus rapides aussi. Tout cela a à voir avec le positionnement des données.

S'il y a une chose qui ralentit un disque dur plus que le transfert de grandes quantités de données, c'est le déplacement de ses têtes d'une partie à une autre du disque. Chaque déplacement implique du temps pour que la tête commence à se déplacer, puis s'arrête, puis qu'elle s'assure qu'elle s'est positionnée à la bonne place, puis qu'elle attende que le disque en rotation passe au bon endroit pour y déposer les bits voulus. Physiquement, ce sont des parties mobiles bien réelles, et il est étonnant qu'elles puissent effectuer leur danse aussi vite et aussi efficacement, mais la physique a ses limites. Ces mouvements réduisent réellement les performances pour les systèmes de stockage à rotation que sont les disques durs.

Le format des volumes HFS + stocke toutes ses informations sur les fichiers -les métadonnées- à deux endroits principaux sur un disque : le Fichier Catalogue, qui stocke les dates de fichier, les permissions, l'appartenance, et beaucoup d'autres choses, et le Fichier des Attributs, qui stocke les "fourches nommées".

Les attributs étendus dans HFS + sont implémentées comme fourches nommées dans le fichier des attributs. Mais à la différence des fourches de ressources, qui peuvent être très grosses (jusqu'à la taille maximum de fichier supportée pas le système de fichiers), les attributs étendus de HFS + sont stockés "en ligne" dans le fichier d'attributs. En pratique, cela signifie une limite des 128 octets par attribut. Mais cela signifie aussi que la tête de lecture n'a pas besoin d'entreprendre une migration vers une autre partie du disque pour accéder aux données réelles.

Comme vous pouvez l'imaginer, les blocs du disque qui constituent les fichiers Catalogue et Attributs subissent des accès très fréquents, et pour cette raison, ont plus de chances de se retrouver en cache quelque part. Tout cela concourt à donner au stockage complet d'un fichier, y compris ses méta-données et ses données au sein des fichiers catalogue et Attributs structurés en B-Tree, un gain de performances d'ensemble. Même une charge de 8 octets qui se gonfle à 25 octets n'a pas d'importance, tant qu'elle peut tenir dans un nœud B-tree dans le fichier d'attributs, que de toute façon, le système d'exploitation doit lire entièrement.

Il y a d'autres contributions significatives de Léopard des neiges à la réduction de l'empreinte sur le disque (notamment la suppression des localisations superflues et les fichiers nib adaptables), mais la compression HFS + est de loin la technique la plus intéressante.

L'intelligence de l'installeur

Apple promet deux choses intéressantes à propos du processus d'installation :

Léopard des neiges teste vos applications pour s'assurer qu'elles sont compatibles, et met à part tout programme connu pour être incompatible. Au cas où une rupture de courant interromprait votre installation, il repartira sans perdre aucune donnée.

La mise à l'écart des applications "connues comme incompatibles" est indubitablement une réponse aux problèmes d'écran bleu rencontrés lors du passage de Tiger à Léopard il y a deux ans qui était provoquée par la présence d'extensions système tierces incompatible -certains diraient "illicites"-. J'ai une vision catégoriquement pragmatique de ce genre de logiciels, et suis heureux de constater qu'Apple adopte une approche pratique semblable pour minimiser ses conséquences sur les utilisateurs.

Bien sûr, on ne peut pas s'attendre à ce qu'Apple détecte et invalide tout logiciel potentiellement incompatible. Je soupçonne que seulement les logiciels les plus populaires ou ceux à plus hauts risques sont identifiés. Si vous êtes un développeur, cette caractéristique de l'installeur peut être une bonne façon de savoir si vous êtes sur la liste noire d'Apple.

Quant à la poursuite de l'installation après une panne de courant, je n'ai pas eu le toupet de tester cette possibilité (et j'ai un onduleur). Pour des opérations qui durent longtemps comme une installation, ce genre de sécurité est bienvenu, notamment pour les ordinateurs avec une batterie comme les portables.

Je mentionne ces deux détails du processus d'installation, principalement parce qu'ils illustrent le genre de choses qui est possible quand chez Apple, on donne le temps aux développeurs de polir leurs composants respectifs du système d'exploitation. Vous pourriez penser que l'équipe d'installation a été pressurée pour venir à bout de suffisamment de choses pendant un cycle de développement d'environ deux ans. Visiblement, ce n'est pas le cas, et ce sont les consommateurs qui en moissonnent les bénéfices.