Notons d'emblée que MacOS a commencé comme un BSD 4.2g (Net/2) Single Server sur un Mach Microkernel...
La chose la plus simple à faire est de choisir votre BSD, puis de commencer à changer les choses que vous voulez changer à son sujet.
La façon de faire est de configurer un système comme système cible de test, et vous configurez un système séparé comme votre environnement de développement, et exécutez un BSD non altéré dans celui-ci.
À partir de là, vous pouvez configurer un répertoire source alternatif - je le ferais en copiant l'arbre source sur une autre partition - et ensuite définir un répertoire de destination dans l'environnement de construction pour cibler une troisième partition.
Cette troisième partition peut être soit sur un support amovible, pour faire l'image amorçable que vous emmenez ensuite sur votre système de test, soit sur une cible SCSI, et vous pouvez l'héberger en double - ce qui signifie que vous pouvez y accéder via le protocole SCSI depuis le système de construction, ou alternativement, le système cible.
Nous avons utilisé un système SCSI chez Whistle/IBM pour développer des mises à jour logicielles pour l'UFS de FreeBSD.
Mes préférences personnelles seraient d'implémenter à partir d'une certaine version de FreeBSD, à moins que votre architecture cible ne soit pas supportée.
La principale chose que vous voudrez changer - et la raison pour laquelle les systèmes BSD et Linux n'ont pas réussi à décoller dans l'espace de bureau - est les services d'affichage, les pilotes graphiques, et la création d'une boîte à outils GUI unique.
Si les programmeurs ont le choix, ils prendront des décisions qu'il vaut mieux laisser au marketing.
En ne fournissant qu'une seule boîte à outils, vous garantissez que les tiers ont un seul environnement de développement à cibler.
Vous devez concevoir cela avec soin, car vous voudrez maintenir une rétrocompatibilité binaire pour les anciennes applications, en allant de l'avant, afin qu'un développeur puisse cibler votre plate-forme, et s'attendre à ce que les ventes continuent à progresser pendant au moins une décennie.
Vous devrez minimalement porter le navigateur Chromium sur votre plateforme, et vous voudrez préférentiellement le porter de telle sorte qu'Adobe soit prêt à fournir un composant flash.
Vous devrez intégrer la signature de code, et des sections du format binaire ELF (en supposant que vous vous en teniez à ELF) aux blocs de signature, de telle sorte que vous puissiez câbler les signatures de code dans le chemin de pagination des images exécutables.
C'est le minimum que vous devrez faire pour fournir des binaires sécurisés auxquels les utilisateurs pourront faire confiance.
En cela, une certaine considération pourrait être accordée à un format alternatif d'exécutable. Cela permettrait une discrimination facile entre les binaires " ancien style " et " nouveau style " ; cela vous permettrait également de " désactiver " certains supports binaires, et à un moment donné dans le futur, cela vous permettra de savoir si oui ou non vous avez atteint une marque de " cut over ", ou s'il y a encore du travail à faire pour devenir autonome.
This is not unprecedented, of course.
Juniper Networks JunOS is FreeBSD based, as is Sony’s Orbis OS, used on the Playstation 4 (Orbis is based on FreeBSD 9).
But it’s a lot of work.