Mise à jour 19 avril 2015 :
Deux ans plus tard, il semble que ce domaine ne suscite toujours pas beaucoup d'intérêt. Cependant, la communauté Hackintosh est toujours très active, ce qui signifie que l'un des rares bootloaders open source non-Apple capable de démarrer xnu (Chameleon et forks) est toujours maintenu et peut démarrer Yosemite. Il existe également des exemples de démarrage réussi d'OS X Yosemite dans QEMU. De plus, grâce à un développeur (maintenant employé par Apple) qui se fait appeler winocm , nous avons un Portage ARM du noyau xnu . Elle a été le développeur le plus actif que je connaisse dans cette région.
Il y a également une suite à Mac OS X Internals d'Amit Singh à venir. D'habitude, je n'aime pas mentionner les pages personnelles des gens ; cependant, le serveur du blog contenant toutes les informations semble ne pas être fiable. de ameaijou Page Twitter.
J'ai réussi à construire la chaîne d'outils de développement d'Apple (un auto-hébergement, cependant le "Darwin SDK" a également été porté sur Linux ). Je pense qu'il est encore possible de construire un système d'exploitation Darwin à partir de zéro - il ne nous manquerait plus que quelques Kexts open-source. Surveillez 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 Binary Cheats : Probablement, mais aussi pas 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 de la Californie*)
Réponse plus longue :
Cela va être assez long. Je vous conseille de prendre un café. Si vous n'avez pas le temps ou l'envie de tout lire, vous pouvez passer directement aux "Remarques finales".
Pratiquement possible (non) :
Malheureusement, Apple a retiré le code source d'un trop grand nombre de ses produits. Les KEXT nécessaires à Darwin et des binaires pour rendre possible la compilation d'un système d'exploitation Darwin à partir des sources. C'est toujours techniquement possible (vous pourriez écrire le code source vous-même pour le 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 par la foule soit très intéressée).
Sans surprise, le point de bascule a été la sortie de Darwin 10, qui a permis à xnu d'entrer dans le monde x86_64. La plupart des sources nécessaires existaient déjà avant cette date, mais n'étaient disponibles que pour x86. Au fil du temps, la signification de l'expression "Open Source" d'Apple semble s'être transformée en "Open Source sur le matériel Apple uniquement", car les KEXT d'Apple sont désormais en grande partie spécifiques au matériel, de sorte que même si vous parveniez à tout faire fonctionner (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 il est certain que toute la configuration nécessaire peut être effectuée sans avoir à 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 KEXTs et le bootloader. J'ai cependant réussi à résoudre le problème du bootloader (au 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 Mac OS Extended (Journaled) (HFS+).
-
Assurez-vous qu'il dispose d'une table de partition GUID (GPT) et, le cas échéant, d'une partition EFI. La façon la plus simple de procéder est d'utiliser l'Utilitaire de disque d'Apple, mais vous pouvez le faire en ligne de commande si vous le souhaitez (vous trouverez ailleurs des tutoriels 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
Supports en lecture seule : Non
Volume en lecture seule : Non
-
Il s'agit maintenant de suivre le guide LFS (avec des adaptations).
-
Insérer DFS=/Volumes/_DarwinOS_ (en utilisant le point de montage actuel, évidemment) dans .bashrc y .bash_profile
-
Créez le répertoire de l'utilisateur ( chown à 0:0 à la toute fin) :
sudo mkdir -v "$DFS"/usr
-
Entrer root :
sudo su -
-
Créez le répertoire des sources et mettez en place 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 tools et créez un lien symbolique vers celui-ci afin de pouvoir l'ajouter facilement à $PATH par la suite (toujours dans root d'ailleurs) :
mkdir -v "$DFS"/tools
ln -sv "$DFS"/tools /
logout # Leave root
-
Téléchargez les sources de tous les paquets que vous souhaitez. C'est là, bien sûr, que vous vous retrouvez bloqué. Tous ceux qui sont nécessaires ne sont pas là. (Soit dit en passant, je préfère le paquetage de GNU binutils Quoi qu'il en soit.)
En supposant que vous ayez pu télécharger tous ceux dont vous aviez besoin, poursuivons.
-
Créer 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 d'accueil 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
-
Se connecter :
su - lfs
Password: dfs
-
Exécutez la commande suivante pour nettoyer l'environnement (à partir de 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 savoir 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
-
Le CCG /configure est assez flexible. Essayez d'extraire le code *- ou simplement exécuter gcc -v pour voir comment votre machine hôte a été configurée et copiez-la.
-
Déconnectez-vous de l'utilisateur lfs et reconnectez-vous. Vous devriez maintenant avoir un environnement propre.
-
À partir de maintenant, tout se passe à l'intérieur de l'utilisateur lfs. Vous remarquerez que j'ai été un peu paresseux en ne convertissant que la moitié des symboles 'LFS' en symboles 'DFS'. Je m'en excuse, mais vous avez compris l'idée.
Passons maintenant à la partie hypothétique.
À partir de maintenant, il s'agit d'une procédure standard pour les points de vente au détail : Extraire les sources, construire, 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 fonctionnelle de libc++.1.dylib - et vous devrez également le faire en deux fois. Vous pouvez consulter la page page libcxx pour plus de détails. Une fois compilé, vous pouvez le placer dans /usr/lib . Vous devrez compiler et installer le noyau xnu (il y a une série d'options de compilation). quelques tutoriels sur le web pour savoir comment procéder), puis installer les KEXT. Même si tous les KEXTs nécessaires étaient disponibles, vous devriez les intégrer manuellement dans le paquet .kext. Encore une fois, il y a sont des tutoriels pour savoir comment créer un KEXT à la main sur la ligne de commande.
La dernière étape consiste à rendre le système amorçable. Pour ce faire, vous devez exécuter la commande suivante :
"$DFS/usr/sbin/bless" --folder "$MOUNT/System/Library/CoreServices" --bootefi --verbose
En fait, le lieu de la bénédiction ne fait pas vraiment de différence. Ce dossier fait partie de la norme Apple.
Dans tous les cas, en supposant que le noyau et les KEXT soient au bon endroit, vous aviez les bonnes copies de dyld , launchd etc. en place et boot.efi fonctionnait correctement, le système devrait fonctionner et être amorçable !
Remarque : si vous le vouliez vraiment, vous pourriez mettre en place un faux launchd qui est juste un script pour lancer une invite bash - c'est ce que PureDarwin Nano ne.
Encore une fois, n'hésitez pas à écrire les KEXTs et les binaires vous-même si vous le souhaitez. est techniquement possible. Appelez-moi quand vous aurez terminé.
Avec Binary Cheats : Probablement, mais aussi pas légal (non testé)
Alors, pourquoi ne pas simplement extraire les binaires, les KEXT et les fichiers nécessaires de Mountain Lion, bénir le volume et partir ? Eh bien, c'est probablement possible. 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 un peu hors sujet ?
Avec Binary Cheats pour le matériel générique : Comme ci-dessus (non testé)
C'est à peu près est le projet OSx86. Là encore, on se heurte directement à des problèmes juridiques. Il ne fait aucun doute que ces deux dernières méthodes sont tout à fait possibles - le fait que vous puissiez faire fonctionner Mountain Lion sur du matériel générique en est la preuve - mais l'objectif principal était de pouvoir compiler légitimement votre propre système d'exploitation Darwin à partir des sources.
Note de bas de page
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 beaucoup d'intérêt à compiler un système 32 bits. Apple a effectivement fourni des images disques de Darwin (jusqu'à Darwin 9). aquí . Ils ont parfaitement fonctionné sur ma boîte Windows.
Remarques finales
Je pense qu'en fin de compte, les gens n'achètent pas Mac pour Darwin, ils achètent Mac pour Aqua. En conséquence, le soutien à Darwin en tant que produit autonome à code source ouvert a progressivement diminué au point qu'il n'est plus qu'un geste symbolique à l'égard de la communauté à code source ouvert. L'autre fait légèrement ironique est que pour en savoir plus sur tout cela, il faut se lancer dans le projet OSx86, qui n'est pas vraiment sanctionné (pour dire les choses crûment). Même dans ce cas, il n'y a pas beaucoup d'informations disponibles. 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 le xnu.
Cette année de travail a été extrêmement instructive, et je suis presque aussi heureux de savoir comment faire que de le faire réellement. Il faudra bien que j'arrête de travailler dessus à un moment ou à un autre, et c'est maintenant que ça se passe. En guise de dernier cri futile à Apple, serait-ce trop demander que d'avoir juste une version supplémentaire de Darwin lorsque vous sortirez Mavericks ?
