John Siracusa

Le lancement

Préface

Le sujet de cette section peut sembler ésotérique, ou pas digne d'un rapport détaillé. J'ai choisi de le faire, pas tellement parce que c'est un élément significatif de Tiger, mais plutôt parce qu'il met en lumière quelques aspects du processus de développement chez Apple.

Cela va être très orienté Unix, très rapide. Je vais expliquer autant que je peux, mais cela ne va pas être une formation Unix à partir des principes de base. Si tout cela est du grec pour vous, vous pouvez toujours passer à la section suivante.

Quelques bases

Sous Unix en général, et dans Mac OS X en particulier, il y a un tas de façons de lancer des programmes en réponse à des événements externes, ou sur un séquencement temporel. Les événement courants incluent le démarrrage du système, son arrêt, le redémarrage et l'ouverture de session, et les connections réseau entrantes et sortantes.

Sous Unix, les événements de démarrage, d'arrêt et de redémarrage sont gérés par une série de scripts shell interconnectés localisés dans /etc/rc.d. Le chemin exact et le contenu de cette arborescence varient. Quelques versions Unix utilisent un mécanisme tout à fait différent, mais la plupart gardent les traces de leur filiation BSD ou System V.

L'exécution basée sur le temps est habituellement gérée par les démons cron ou at. Les événements d'ouverture de session sont déclenchés par des fichiers spécifiques (dont le nom commence par un point) stockés dans le répertoire principal (home) de l'utilisateur. Les connections de réseau peuvent être prises en charge par des démons spécifiques, ou par l'un des nombreux "super démons" (par exemple inetd) qui organisent les connections réseau, et déclenchent d'autres démons quand c'est nécessaire. Mac OS X fait tout cela, et il a en plus ses propres mécanismes gérés par XML, pour le démarrage du système et les items d'ouverture de session d'un utilisateur, qui sont indépendants de la couche Unix.

Tous ces systèmes souffrent de limites. Les super démons réseau, en particulier sont limités par des pré-supposés sur leur fonction. La plupart des super démons sont orientés IP, et supposent une seule connexion réseau par démon. Ils s'étendent normalement à tout le réseau, ce qui les rend incapables, par exemple, de lancer un démon pour le compte d'un utilisateur particulier. Ils ont aussi tendance à s'affranchir de leurs responsabilités, dans un environnement informatique moderne. Un Power Book, par exemple, peut se mettre en sommeil dans un espace du réseau, et se réveiller dans un espace réseau tout à fait différent.

Lorsque de nouveaux besoins de lancement de programmes sont apparus dans le monde Unix, la tentation a toujours été de modifier, ou de se reposer sur, l'un des systèmes existants. Par exemple, le démon ssh-agent (pensez "trousseau pour des mots de passe SSH") doit se lancer une fois (et une seule) pour chaque session d'un utilisateur. Les fichiers de démarrage du shell (la coquille) sont lus à chaque fois que le shell démarre. Plusieurs fenêtres de terminal signifient plusieurs shells, mais une seule session.

La solution de la communauté Unix a été de faire des tests au démarrage d'un shell pour savoir si ssh-agent était déjà lancé, ou le lancer s'il ne l'était pas. D'une bidouille habile cela est devenu une pratique courante à mesure que le ssh-agent devenait plus connu. C'est un bon exemple de "la manière Unix".

A chaque fois que les vendeurs Unix sont allés à contre-courant, et essayé de proposer quelque chose de plus qu'une petite amélioration aux mécanismes existants, ils se sont heurtés à une résistance instinctive. Regardez seulement cette estimation d'un utilisateur Unix sur le nouveau système de gestion de service de Solaris 10.

Mon point de vue, au sujet de SMF (Service Management Framework) est qu'il n'est pas aussi transparent qu'un système comme rc.d dans NetBDS/FreeBSD, ou même le vieux init de SysV. Il est encore très facile à comprendre, mais il y a un niveau de "magie" qui n'existait pas auparavant

En tant qu'utilisateur intensif d'Unix moi-même, je peux deviner d'où vient cette personne. Mais honnêtement, seulement quelqu'un en immersion absolue dans la culture Unix peut seulement prétendre que rc.d ou init de System V sont réellement "transparents". SMF utilise des scripts shell, mais aussi XML. C'est un nouveau tournant pour des spécialistes Unix de la vieille école, et il faut s'attendre à ce que la réaction initiale soit prudente.

Apple a suivi le même chemin que Solaris, en rajoutant ses propres mécanismes gérés en XML pour le démarrage et l'ouverture de session. La communauté Unix a très largement ignoré ces efforts. Elle avait ses scripts shell, ses super démons, et ses échafaudages basés sur /etc/rc.d.

Mais Apple n'est pas votre vendeur Unix typique. Puisque les nouveaux systèmes basés sur XML étaient bien, ils ont rajouté deux systèmes de plus à cet ensemble déjà bien peuplé. Dans Tiger, Apple a décidé de s'attaquer à nouveau au démarrage des programmes, cette fois en effaçant complètement l'ardoise.

Launchd

Pour Tiger, Apple a créé launchd : un démon de démarrage pour les gérer tous. Launchd fait le travail de tous les mécanismes de démarrage des programmes existants, et le fait avec le moins de nuisances possible pour les programmes qu'il lance. Les processus créés par launchd n'ont pas à se préoccuper de se muer en démons, de tester les dépendances, de relancer, ou de maintenir les canaux de communication actifs en cas de crash.

Lauchd peut lancer des programmes en réponse à chacun des événements cités ci-dessus, et il peut le faire sur demande du système ou d'un utilisateur. Il va trouver seul les dépendances, et lancer des programmes en parallèle quand c'est possible. C'est essentiel pour un démarrage rapide du système. Les éléments du système de démarrage ancien de Mac OS X faisaient la même chose, mais il fallait leur fournir explicitement les dépendances.

Launchd supporte un protocole de messages pour répondre à des questions du genre : "Combien d'utilisateurs sont connectés à ce démon ?" ou "Avez vous déjà fermé ?". L'arrêt des programmes est un autre exemple d'un espace dans lequel "la manière Unix" est habituellement considérée comme "suffisamment bonne" malgré des défauts évidents. Traditionnellement, les services Unix sont fermés en envoyant un signal au processus, en attendant un peu, puis en renvoyant un signal plus contraignant, pour le cas où le service aurait refusé de se fermer. C'est une pratique barbare, mais indispensable parce qu'il n'y a pas de systèmes de messages standardisé pour les démons Unix. Launchd a identifié le besoin, et y a remédié.

Apple a développé launchd comme un projet Opens source, et espère qu'il sera adopté par une communauté Unix plus large. Pour le spécialiste Unix moyen, launchd ressemble probablement à la ré-invention de la roue. Je crois qu'il résoud un problème que la communauté Unix ne sait même pas qu'elle a. Dans cette voie, c'est tout à fait comme Mac OS X . Il y avait "Unix sur le bureau", puis il y a eu Mac OS X. Vous devriez considérer que cela seul constitue un appel suffisant à se réveiller.

Si je travaillais sur un système d'exploitation basé sur Unix, j'emprunterais des idées et du code à Apple, sans scrupules. Apple a sans doute été assez habile pour tirer dans la direction opposée, en basant la plus grande partie de son OS (notamment du serveur) sur des projets open source. Apple a renvoyé l'ascenseur en contribuant à beaucoup de ces projets : FreeBSD, gcc, KHTML/KJS, etc. Quand Apple se présente avec ses propres créations Unix open source, je pense qu'il est fou de ne pas y prêter attention.

Bon, assez de discours. Ce que launchd signifie pour Mac OS X, c'est que toutes les procédures de lancement des programmes pré-éxistants vont lentement migrer sur launchd. Cela ne va pas se produire du jour au lendemain, ni même dans les années qui viennent, mais les fondations ont été posées. Il y a aussi des plans pour étendre launchd pour prendre en compte les événements de périphériques (comme le branchement d'un appareil photo) et standardiser par la suite, pas seulement le protocole, mais aussi le contenu du service de messages.

Comme lookupd précédemment, launchd s'attaque bille en tête à un problème Unix existant de longue date. Il est ambitieux sans honte, fait exactement de qu'Apple veut qu'il fasse, sans considérations inutiles sur la façon dont c'était fait dans le passé. Les noms eux-mêmes, "lookupd" et "launchd" révèlent la manière directe, efficace que Apple apporte à tous ses développements relatifs à Unix. "Suffisamment bon" n'est jamais assez bon pour l'équipe du core OS d'Apple, et j'en suis heureux.