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

Mountain Lion : la revue de Ars technica (18)

Là où Lion a trébuché, Mountain Lion regroupe et va de l'avant.

Par John Siracusa, 25 Juillet 2012


La gestion de l'énergie

Ce n'est pas une coïncidence, que le dernier et le plus prestigieux Mac soit un ordinateur portable. La dernière année où Apple a vendu plus d'ordinateurs de bureau que de portables était en 2003. Dans le domaine du matériel, des avancées significatives ont été faites depuis. L'évolution vers des batteries scellées sur les portables a apporté une certaine irritation, mais aussi une augmentation importante de la capacité d'énergie. Cela continue aujourd'hui avec des composants électroniques à basse consommation et des batteries plus grosses dans chaque nouveau Mac portable.

Le côté logiciel de l'équation énergétique retient un peu plus d'attention dans Mountain Lion. Dans les versions précédentes d'OS X, l'OS attendait au moins une minute d'inactivité du disque avant de mettre le système en veille. Cette décision pouvait être reportée au dernier moment par n'importe quelle application qui préférait conserver le système éveillé.

Cette stratégie d'un système qui réclame timidement une réduction du mode de puissance après un délai poli est loin d'être optimale. Que se passe-t-il si l'application qui a annulé la demande de veille a terminé son travail au bout de 10 secondes ? L'OS attendra encore pendant une minute entière l'inactivité du disque avant même de tenter de remettre le système en veille.

Dans Mountain Lion, OS X ne fait plus attention à l'activité du disque quand il décide qu'il est temps de mettre le système en veille. Apple recommande à la place que les applications fassent ce qu'elle appelle des "revendications énergétiques" pour dire à l'OS qu'elles sont en train d'effectuer un travail utile, et que le système doit rester éveillé. La ligne de conduite autorise l'OS à mettre le système en veille à partir du moment où il n'y a pas d'applications ayant des revendications énergétiques susceptibles d'empêcher la mise en veille.

Une ligne de conduite de veille plus agressive est bonne pour la durée de la batterie, mais un Mac moderne a aussi du travail à faire même quand il n'y a pas d'utilisateur. Il y a des documents à indexer, des fichiers à sauvegarder, et des mises à jour à télécharger. Il y a des tâches exigeantes en temps qu'il vaut souvent mieux faire à un moment où elles n'encombrent pas le travail courant de l'utilisateur. Elles sont aussi importantes. Si un Mac peu utilisé se met en veille si rapidement après chaque session qu'il n'a aucune chance de faire une sauvegarde sur Time Machine, l'utilisateur aura raison de condamner Apple, pas ses propres habitudes de travail, quand il efface accidentellement un fichier, et trouve ses sauvegardes misérablement dépassées ou inexistantes.

C'est là que Power Nap (veille énergétique) entre en jeu, une caractéristique conçue pour s'assurer que les tâches essentielles d'entretien ne sont pas négligées, même sur un Mac qui passe l'essentiel de son temps en veille. Le nom est en réalité un peu mal choisi. Power Nap oblige votre Mac à se réveiller périodiquement pour faire du travail qui n'est pas prévu. Cependant, le système ne se réveille pas complètement. Il entre dans un mode qu'Apple appelle DarkWake (veille sombre). Dans ce mode, les systèmes audio et graphiques restent inactifs, mais le disque, le CPU et le réseau sont actifs.

DarkWake est en réalité en place depuis Snow Léopard dans lequel il était utilisé pour envoyer périodiquement une interrogation sur le réseau pour s'assurer qu'un Mac en veille ne perde pas son bail DHCP. Sous Lion, brancher ou débrancher un appareil USB pouvait brièvement mettre un Mac sous DarkWake pour re-configurer le bus du périphérique avant de revenir en sommeil. Mountain Lion fait tout ce qui précède, tout en se réservant un peu de temps pour faire le travail quand le maître est absent.

Pour le moment, DarkWake est une caractéristique propre à Apple. Les développeurs tiers ne peuvent pas l'utiliser, ni définir une tâche importante qui puisse tourner avec. Néanmoins, DarkWake n'empêche pas les applications de tourner. L'ordonnanceur de l'OS est complètement éveillé. Les applications tierces qui se retrouvent en train de tourner sous DarkWake devront accepter de bonne grâce de renoncer aux sous-systèmes graphique et audio. Mountain Lion supprime aussi beaucoup de notifications quand il est en mode DarkWake, y compris les possibilités de veille/réveil, et l'accessibilité au réseau.

Avant que vous ne soyez trop excité(e) par DarkWake, vous devez savoir qu'il requiert un "portable Mac avec un stockage flash intégré". D'après Apple, cela veut dire le Mac Book Air (mi-2011 ou plus), le MacBook Pro avec affichage rétina, et c'est tout. (Même dans ce cas là, cela peut exiger une mise à jour du firmware).

L'exigence d'un SSD se justifie si vous considérez que Power Nap arrête aussi les ventilateurs de refroidissement sous DarkWake. Un disque dur qui exécute une sauvegarde Time Machine complète nécessite obligatoirement un refroidissement actif. Power Nap a besoin de stockage SSD intégré parce que les disques électroniques qui sont supposés remplacer les disques durs classiques en rotation ont des besoins en énergie très différents. Si bien que, même si votre MacBook Pro (non Rétina) provient de chez Apple avec un SSD, Power Nap n'y est pas disponible.

Apple encourage aussi ses développeurs tiers à rendre leurs applications moins énergivores. A la WWDC de cette année, une session a été consacrée à sensibiliiser les développeurs à la gestion logicielle de l'énergie ( session 711, pour ceux qui ont accès aux vidéos de la WWDC). Les applications iOS ont toujours vécu dans un environnement où chaque watt d'énergie était précieux. Comme dans tant d'autres domaines, il s'avère que le Mac est conduit dans la même direction.


Les pièces manquantes.

Mountain Lion fait un bon travail pour corriger les déficiences de Lion. Mais plusieurs zones de problèmes subsistent, y compris celles qui sont antérieures à Lion. En voici seulement quelques unes.

HFS+ à jamais

Le système de fichiers par défaut de OS X demeure HFS+, qui ne rajeunit pas. Mon rapport sur Lion de l'an dernier a détaillé les problèmes de HFS+. Lion offrait un peu d'espoir, avec Core Storage, le nouveau gestionnaire de volumes logiques d'Apple, qui a été utilisé pour mettre en place l'encryptage de tout le disque avec File Vault 2. A l'époque, je me demandais si la technologie de Core Storage ne pouvait pas être utilisée comme point de départ d'un nouveau et meilleur système de fichiers. Hélas, Mountain Lion n'apporte rien de semblable.

Plein écran et moniteurs multiples

Lion avait introduit un nouveau mode plein écran pour les fenêtres. Cette caractéristique a immédiatement soulevé la colère des utilisateurs qui avaient de multiples écrans, parce quelle couvrait tous les écrans sauf un d'une texture de toile grise plutôt que de les rendre disponibles pour d'autres utilisations. Mountain Lion permet à toutes les applications de passer en mode plein écran sur n'importe quel moniteur, pas seulement sur l'affichage primaire. C'est un peu mieux, mais les autres écrans sont toujours en toile grise.

Je suppose que la question est de savoir comment les fenêtres et un changement d'application réagissent avec des fenêtre plein écran sur des affichages multiples. Est-ce qu'un glissement à trois doigts vers la gauche remplace seulement le contenu de l'affichage primaire ? Ne pourrait-il pas décaler toutes les fenêtres plein écran d'un moniteur vers la gauche ? Il n'y a sans doute pas un ensemble de comportements dans cette situation qui ne surprendrait ou ne gênerait une certaine partie de la base d'utilisateurs. Si bien qu'Apple s'en tient au modèle le plus simple, qui gène aussi une partie de sa base d'utilisateurs. Personne n'a dit que c'était là une chose facile.

La terminaison automatique

La nouvelle caractéristique de terminaison automatique de Lion a aussi ébouriffé quelques plumes. Son but est de rapprocher la gestion d'application d'OS X du modèle iOS, dans lequel l'OS décide lui-même d'éliminer une application de la mémoire. Mais les règles que l'OS utilise pour prendre ces décisions, entrent souvent en conflit avec les souhaits de l'utilisateur.

Un seul exemple. J'utilise souvent Aperçu pour visualiser des images et lire des PDFs tout en écrivant ce rapport. Un double-clic sur un PDF dans le Finder lance Aperçu, et je commence à lire. Quand j'ai fini, je ferme le PDF, et je peux passer à une autre application. Immédiatement après le passage à l'autre application, Aperçu quitte, et disparaît de mon Dock. c'est le résultat des règles de la terminaison automatique qui décide que les applications inactives, qui n'ont pas de fenêtre ouverte, peuvent se terminer.

Sur le papier, cela semble logique. Si je veux voir un autre PDF ou une autre image, je peux simplement double-cliquer dans le Finder, et Aperçu va se relancer. Où est l'intérêt de laisser Aperçu en route alors qu'il n'affiche rien ? Le problème est que, pour moi, je suis encore en train d'utiliser Aperçu. Si bien que quand le moment vient de voir une autre image, mon premier mouvement est de revenir à Aperçu en utilisant le Dock. Mais quoi, Aperçu n'est plus dans le Dock ? Pourtant, j'étais encore en train de l'utiliser !

Le changeur d'applications de iOS résout ce problème en affichant une liste des applications récemment utilisées. Son rôle est beaucoup plus limité que celui du Dock d'OS X qui prétend servir de lanceur d'applications, de changeur d'application, de gestionnaire de fenêtre, et d'espace de parking pour les fichiers et les dossiers. Si j'avais placé Aperçu en permanence dans le Dock, il y serait resté après la terminaison automatique. Mais toutes les applications ne peuvent pas être dans le Dock tout le temps. Quelque chose doit changer.

Malheureusement, Mountain Lion présente le même comportement gênant que Lion dans ce domaine. Le problème aurait pu être corrigé en modifiant les règles de terminaison automatique d'une certaine façon, peut-être en ajoutant un délai avant la terminaison automatique. Mais le problème fondamental est la nature multi-fonctionnelle du Dock. Si OS X avait un changeur d'applications séparé, de type iOS, le modèle d'application géré par le système iOS serait une bien meilleure solution.