Apple publie les composants open-source d’OS X Yosemite
OS X n’est pas open-source, mais certains de ses composants le sont. Apple vient justement de publier le code source de ces éléments et les développeurs intéressés peuvent retrouver l’intégralité des bibliothèques et des autres éléments ouverts en téléchargement à cette adresse.
Cette procédure n’a rien d’exceptionnel et Apple le fait d’ailleurs à chaque sortie d’un nouveau système. Cette année, on note toutefois un absent dans la liste : launchd, le framework qui lance et arrête les applications, processus et scripts sous OS X. Ce framework n’est plus open source, mais n’y cherchez pas de la mauvaise volonté de la part d’Apple.
Comme l’explique cet article technique, Apple a complètement réécrit launchd pour OS X Yosemite et iOS 8. Le constructeur a utilisé un autre élément pour écrire ce composant et cet élément n’est pas open source. Pourquoi avoir changé ? On ne sait pas exactement, mais il est probable que ce soit lié aux nouvelles extensions (claviers sur iOS, partage, widgets, etc.)
launchd joue désormais un rôle essentiel pour contrôler les extensions au lancement des deux systèmes et on imagine que c’est pour cette raison qu’Apple a été obligé de le réécrire. D’où, probablement aussi, son absence dans la liste.
Qu'ils aient une excuse ou non, on ne va pas dans le bon sens pour l'Open Source.
Une excellente nouvelle pour des milliers de développeurs seraient qu'ils rendent Open Source leurs applications de base sur iOS et OS X. Je parle de Contacts, Plans, Notes, etc...
J'ai récemment développé une app qui intègre un annuaire, et je voulais qu'elle soit la plus proche possible de l'app Contacts officielle. J'aurais été heureux d'avoir un modèle dont je puisse regarder le code.
@PiRMeZuR :
Pour quelle plateforme ?
Désolé mais j'ai du mal à voir l'intérêt de la planète dans cette démarche. Y a plein de projets open source pour ce genre de petites apps.
Par ailleurs, j'aime pas du tout cette manie de la communauté Open Source de faire des copies des programmes existants. Je trouve ça malhonnête.
Si t'as une idée singulière à proposer, développe là. Si tu veux offrir ton travail à la planète, bravo, c'est tout à ton honneur. Mais respecte qu'on ait pas forcément envie que quelqu'un offre ton boulot à ta place.
Juste pour info, j'ai une amie qui développe depuis des années un univers graphique (recherche "Les Folles Marquises") qui vient de se faire piller son travail par une boîte chinoise. C'est sympa de leur part d'offrir le travail d'une décennie au plus grand nombre, mais ça reste du vol pur et simple.
C'est toute la question de se faire rémunérer un travail (planification) ou espérer en tirer une rente (spéculation) que tu soulèves là. Une problématique plus profonde que l'open source dans un monde qui tend à être de plus en plus ouvert et connecté, un problème que l'on retrouve jusque dans les photos de monuments. Il faut réellement repenser la propriété intellectuelle car il est clair qu'une partie du monde ne veut pas jouer avec nos règles.
@PiRMeZuR :
Ça c'est du vol...
Tu veux faire un gestionnaire de contact ? Invente t'as propre interface...
En plus mettre c'est éléments open source faciliterais la fraude ! Imagine un hacker qui reproduit l'appel contact afin de récupéré et revendre c'est information ou envoyer automatiquement du spam depuis mail.app
Comme souvent sur Internet, vous parlez sans connaître. L'app que j'ai développé donnait accès à plusieurs annuaires en ligne et n'avait donc pas pour but de remplacer l'app d'Apple. Comme je trouvais bien foutue cette dernière et que j'intégrais la possibilité d'ajouter la fiche d'une personne à l'app Contacts officielle, j'ai essayé de rendre les deux le plus similaire possible pour rendre la chose intuitive.
Et, croyez-le ou non, il n'existe aucun exemple d'app de contacts sur le net en Obj-C...
Comme vous le dites, launchd sert à charger les extensions (kext).
Apple a réécrit launchd.
Or depuis Yosemite, les extensions doivent obligatoirement être signées (ce qui pose problème à Trim Enabler).
On dirait bien que les deux sont liés, non ?
non
cela ne serait pas une raison acceptable.
Un système de signature par clé a juste besoin de garder la clé privée pour signer heu... privée; donc de pas la fournir avec le code source.
@ oomu
Peut-être que « ça ne serait pas acceptable », mais ça ne m'étonnerait pas.
On peut très bien imaginer qu'Apple ne veuille désormais pas qu'on voie dans le détail comment sont chargés les kext - ou pas; pour éviter que le système soit hacké, càd que des kext non signés puissent être chargés même si la vérification est demandée.
En d'autres termes, on peut se foutre des clefs si on peut changer la serrure ou si on sait comment elle marche pour lui faire croire qu'on a la bonne clef ! On peut donc imaginer qu'Apple ne veuille plus qu'on voie comment fonctionne la serrure.
prochaine étape : HealthKit et HomeKit ??
@nicolas :
Pour que chacun puisse se targuer d'une certification HealthKit et HomeKit sans rendre de compte ? Jamais de la vie.
C'est déjà difficile de faire comprendre qu'une faille de sécurité dans un navigateur WebKit ne signifie pas forcément une faille de WebKit, là ça va juste être impossible, et les concurrents n'attendent que ça de pouvoir jouer sur ce genre de mots douteux.
Ce qu'il manque, surtout, c'est le pilote des disques SSD ;-)
D'ailleurs en parlant de ça, si des gens ont trouvés comment utiliser les nouvelles commandes de launchd !? load marche encore mais c'est étiqueté "legacy"
Je m'en souviens même