Est-il possible de compiler une distribution Darwin à partir des sources, comme vous pouvez créer une distribution Linux ?

Mise à jour du 19 avril 2015 :

Après deux ans, il semble qu'il y ait encore très peu d'intérêt pour ce domaine. Cependant, la communauté Hackintosh est toujours très active, ce qui signifie que l'un des rares chargeurs de démarrage open source non Apple capables de démarrer xnu (Chameleon et forks) est toujours maintenu et peut démarrer Yosemite. Il existe également des exemples de réussite du démarrage d'OS X Yosemite dans QEMU. De plus, grâce à un développeur (maintenant employé par Apple) qui passe par le pseudo winocm , nous avons un port ARM du noyau xnu. Elle a été la développeuse la plus active que je connaisse dans ce domaine.

Il y a aussi une suite à Mac OS X Internals d'Amit Singh à venir. Je n'aime généralement pas mentionner les pages personnelles des gens; cependant, le serveur de blog avec toutes les informations semble un peu peu fiable, alors consultez la boîte d'informations sur la page Twitter d'ameaijou.

J'ai réussi à construire la chaîne d'outils de développement d'Apple (un auto-hôte, mais le "Darwin SDK" a également été porté sur Linux). Je pense qu'il est peut-être encore possible de créer un système d'exploitation Darwin à partir de zéro - à peu près tout ce qui nous manque, ce sont des Kexts open source. Regardez cet espace, et si vous savez comment susciter l'intérêt, faites-le moi savoir ! :)

Réponses courtes à cette question :

Techniquement : Oui

En pratique : Non*

Avec des astuces binaires : Probablement, mais aussi non légal (non testé)

Avec Binary Cheats pour le matériel générique : Comme ci-dessus (non testé)

*sauf si vous travaillez chez Apple (*se racle la gorge en direction générale de la Californie*)

Réponse plus longue :

Cela va être assez long. Je propose du café. Si vous n'avez pas le temps/l'envie de tout lire, vous pouvez passer aux "Remarques finales".

Pratiquement Possible (Non) :

Malheureusement, Apple a retiré le code source d'un trop grand nombre de KEXT et de binaires nécessaires à Darwin pour rendre possible la compilation d'un système d'exploitation Darwin uniquement à partir de la source. C'est toujours techniquement possible (vous pouvez écrire vous-même la source pour la corriger correctement), mais je n'ai tout simplement pas le temps, les compétences ou l'envie de le faire (et je doute que la communauté du financement participatif soit très intéressée).

Sans surprise, le point de basculement clé a été la sortie de Darwin 10, qui a introduit xnu dans x86_64-land. La plupart des sources nécessaires existaient auparavant, mais n'étaient que x86. Au fil du temps, la signification de "Open Source" d'Apple semble s'être déplacée vers "Open Source sur le matériel d'Apple uniquement", car les KEXT d'Apple sont désormais dans l'ensemble spécifiques au matériel, donc même si vous pouviez tout mettre en place et en cours d'exécution (voir ci-dessous), vous seriez toujours confiné au matériel Apple.

Techniquement Possible (Oui) :

Cependant, tout n'est pas perdu. Le guide LFS s'est avéré utile et toute la configuration nécessaire peut certainement être effectuée sans réellement construire le système d'exploitation Darwin. De plus, les étapes présentées vous donnent une feuille de route presque exacte du chemin à parcourir, moins le noyau, les KEXT et le chargeur de démarrage. J'ai cependant réussi à résoudre le problème du chargeur de démarrage (du moins pour le matériel Apple).

Si vous êtes intéressé, voici un aperçu complet de ce que vous devrez faire :

• Effacez une partition (8 Go ou plus de préférence) sur un disque (interne ou externe - peu importe) et formatez-la en tant que Mac OS étendu (journalisé) (HFS+).

• Assurez-vous qu'il a une table de partition GUID (GPT) et que lorsque vous le faites, il a une partition EFI. La façon la plus simple de le faire est d'utiliser l'utilitaire de disque d'Apple, mais vous pouvez le faire sur la ligne de commande si vous le souhaitez (il existe des didacticiels ailleurs sur la façon de procéder). Le point important est que lorsque vous exécutez distil list diskNsM , les informations suivantes doivent être correctes :

  Type de partition :Apple_HFS

  Le système d'exploitation peut être installé :oui

  Média en lecture seule :Non

  Volume en lecture seule :Non

• Maintenant, suivez le guide LFS (avec des adaptations).

• Insérer DFS=/Volumes/DarwinOS (en utilisant le point de montage réel, évidemment) dans .bashrc et .bash_profile

• Faire le répertoire utilisateur (chown à 0:0 à la toute fin) :

  sudo mkdir -v "$DFS"/usr
  

• Entrez root :

  sudo su -
  

• Créez le répertoire des sources et définissez le sticky bit :

  mkdir -v "$DFS"/sources     # Make sure you still have $DFS defined; if not, redefine it.
  chmod -v a+wt "$DFS"/sources
  

• Créez le répertoire des outils et créez-y un lien symbolique afin que nous puissions l'ajouter facilement à $PATH plus tard (toujours en root au fait):

  mkdir -v "$DFS"/tools
  ln -sv "$DFS"/tools /
  logout          # Leave root
  

• Téléchargez la source de tous les packages que vous souhaitez. C'est, bien sûr, où vous êtes coincé. Tous les nécessaires ne sont pas là. (Incidemment, je préfère le binutils de GNU de toute façon.)

En supposant que vous puissiez en fait télécharger tous ceux dont vous avez besoin, continuons.

• Créez un utilisateur défavorisé spécifiquement pour DFS (suggéré par LFS) :

  sudo dscl . -create /Users/lfs
  sudo dscl . -create /Users/lfs UserShell /bin/bash
  sudo dscl . -create /Users/lfs RealName "LFS DFS"
  sudo dscl . -create /Users/lfs UniqueID "2070"      # whatever you like
  sudo dscl . -create /Users/lfs PrimaryGroupID 20    # Default 'staff'
  sudo dscl . -create /Users/lfs NFSHomeDirectory /Users/lfs
  sudo dscl . -passwd /Users/lfs dfs          # Again to taste.
  

• Notez que vous devez créer manuellement le répertoire personnel du nouvel utilisateur sur un Mac :

  sudo mkdir /Users/lfs
  sudo chown -R lfs:staff /Users/lfs/
  

• Accordez maintenant au nouvel utilisateur l'accès aux sources et aux outils

  sudo chown -v lfs $DFS/tools
  sudo chown -v lfs $DFS/sources
  

• Connectez-vous :

  su - lfs
  Password: dfs
  

• Exécutez la commande suivante pour nettoyer l'environnement (depuis LFS) :

  cat > ~/.bash_profile << "EOF"
  echo "Entering clean environment…"
  exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
  EOF
  

• Exécutez maintenant la commande suivante (voir LFS pour ce qu'elle fait si vous n'êtes pas sûr) :

  cat > ~/.bashrc << "EOF"
  set +h
  umask 022
  DFS=/Volumes/*DarwinOS*     # As previously
  LC_ALL=POSIX
  LFS_TGT=$(uname -m)-dfs-darwin1242  # Look inside gcc/configure for possibilities!
  PATH=/tools/bin:/bin:/usr/bin       # Note symlink from before
  export LFS LC_ALL LFS_TGT PATH
  echo ".bashrc script complete. Environment is ready."
  EOF
  

• /configure de GCC est assez souple. Essayez de saisir le *- motif, ou exécutez simplement gcc -v pour voir comment votre ordinateur hôte a été configuré et copiez-le.

• Maintenant, déconnectez-vous de l'utilisateur lfs et reconnectez-vous. Vous devriez maintenant avoir un environnement propre.
• Tout se passe désormais à l'intérieur de l'utilisateur lfs. Vous remarquerez que j'étais un peu paresseux en ne convertissant que la moitié des symboles 'LFS' en symboles 'DFS'. Désolé mais vous voyez l'idée.

Passons maintenant à la section hypothétique.

À partir de maintenant, ce sera plutôt la procédure standard de LFS :Extraire les sources, compiler, installer, tester, supprimer les sources. Notez que les 2 passes de binutils, GCC et Glibc sont toujours nécessaires MAIS vous devez AUSSI avoir une copie de travail de libc++.1.dylib – et vous devrez également le faire en 2 passes. Vous pouvez voir la page libcxx du projet LLVM pour quelques détails supplémentaires. Une fois compilé, vous pouvez le mettre en /usr/lib . Vous devrez compiler et installer le noyau xnu (il existe quelques tutoriels sur le Web pour savoir comment procéder), puis installer les KEXT. Même si tous les KEXT requis étaient disponibles, vous auriez toujours besoin de les mettre manuellement dans le package .kext. Encore une fois, il existe des tutoriels sur la façon de créer à la main un KEXT sur la ligne de commande.

Le dernier bit rend le système amorçable. Pour ce faire, vous exécuterez la commande suivante :

 "$DFS/usr/sbin/bless" --folder "$MOUNT/System/Library/CoreServices" --bootefi --verbose

En fait, l'endroit à bénir ne fait pas vraiment de différence. Ce dossier est juste conforme à la norme Apple.

Dans tous les cas, en supposant que le noyau et les KEXT étaient aux bons endroits, vous aviez des copies appropriées de dyld , launchd , etc en place et boot.efi fonctionnait correctement, le système devrait fonctionner et démarrer !

Notez que si vous le vouliez vraiment, vous pourriez exécuter un faux-launchd c'est juste un script pour exécuter une invite bash - c'est ce que fait PureDarwin Nano.

Encore une fois, bien sûr, écrivez vous-même les KEXT et les binaires si vous le souhaitez - c'est l'est techniquement possible. Appelle-moi quand tu as fini.

Avec des tricheurs binaires :probablement, mais également non légaux (non testés)

Alors, pourquoi ne pouvez-vous pas simplement extraire les fichiers binaires, les KEXT et les fichiers requis de Mountain Lion, bénir le volume et partir ? Eh bien, vous le pouvez probablement. Mais vous avez également besoin d'une licence pour le faire. De plus, si vous faites cela, vous venez de faire une copie de Mountain Lion. N'est-ce pas hors de propos ?

Avec des astuces binaires pour le matériel générique :comme ci-dessus (non testé)

C'est à peu près est le projet OSx86. Encore une fois, vous rencontrez à peu près des problèmes juridiques tout de suite. Il ne fait aucun doute que ces deux dernières méthodes sont tout à fait possibles - le fait que vous puissiez exécuter Mountain Lion sur du matériel générique en est la preuve - mais l'intérêt était de pouvoir légitimement compiler votre propre système d'exploitation Darwin à partir de la source.

Note complémentaire

Vous avez peut-être remarqué que j'ai délibérément évité tout ce qui est 32 bits. Dans un monde où tous les principaux systèmes d'exploitation sont disponibles en 64 bits, il n'y a pas grand intérêt à en compiler un en 32 bits. Apple a effectivement fourni des images de disque de Darwin (jusqu'à Darwin 9) ici. Ils ont parfaitement fonctionné sur ma boîte Windows.

Remarques finales

Je suppose qu'en fin de compte, les gens n'achètent pas Mac pour Darwin, ils achètent Mac pour Aqua. En conséquence, la prise en charge de Darwin en tant que produit open source autonome a progressivement diminué au point qu'il ne s'agit plus que d'un geste symbolique envers la communauté open source. L'autre fait légèrement ironique est que pour en apprendre beaucoup sur cela, vous devez sauter directement dans le projet OSx86, qui n'est pas exactement sanctionné (pour le dire simplement). Même alors, il n'y a pas beaucoup d'informations autour. PureDarwin est un excellent point de départ, et le livre de Jonathan Levin est une référence inestimable pour tout ce qui concerne xnu.

Cette année de travail a été extrêmement instructive et je suis presque aussi heureux de savoir comment le faire que je le ferais réellement. Je vais devoir arrêter de travailler dessus à un moment donné et c'est maintenant que ça se passe. Comme dernier cri futile à Apple, serait-ce trop demander d'avoir une seule version de plus de Darwin lors de la sortie de Mavericks ?