Pourquoi toutes les applications Mac ne sont-elles pas facilement portables sur Linux?

15

Étant donné que le système d'exploitation Apple OS-X est un dérivé UNIX (BSD) et que l'architecture Mac sous-jacente (Intel) est la même, pourquoi n'est-il pas très simple de faire fonctionner des applications spécifiques à Apple sous Linux?

linux macos mac portable bsd Nick Pierpoint
la source

Réponses:

23

OS X est en fait (principalement) le shell graphique propriétaire au-dessus de BSD. Pour créer une application graphique OS X, il faut suivre l'api qu'Apple a exposé, et donc ce n'est pas multiplateforme et pas facilement portable.
C'est pourquoi la plupart des bibliothèques sont facilement portées (en fait, la plupart sont développées sous Linux) vers Linux mais pas leurs shells graphiques.

Sur une note latérale: Il existe des cadres avec lesquels vous pouvez créer des applications GUI multiplateformes. Qt me vient à l'esprit. Mais le fait que ces cadres soient multiplates-formes rend également les applications créées avec eux moins conviviales sur une plate-forme spécifique qu'une application GUI "native". Ces cadres ont tendance à donner à tout un aspect générique sur toutes les plates-formes, ce qui dans le cas d'Apple est mauvais, car Apple a créé une expérience utilisateur très spécifique qui ne s'intègre pas facilement dans d'autres plates-formes.

Modifier (pour incorporer les commentaires dans la réponse - merci @Nick, @kbisset et @John):
Une solution serait de porter l'intégralité du shell graphique OS X (les bibliothèques Cocoa / Core à source fermée - ce qui rend OS X vraiment unique ) à Linux. Et techniquement, Apple pourrait le faire assez facilement, mais ils n'ont aucune raison de le faire, car tout leur modèle commercial est l'unicité de l'ensemble de leur plate-forme - matériel et logiciel.
Il est CONCEVABLE que quelqu'un puisse tenter de cloner les bibliothèques, mais cela prendrait des décennies à faire, et ne serait probablement jamais correct à cause de tous les appels non documentés qui devraient être répliqués.

fretje
la source
Pourquoi le shell graphique propriétaire ne peut-il pas être porté relativement facilement sur Linux s'il s'exécute sur BSD? J'ai compris le problème lorsque l'architecture sous-jacente était différente, mais maintenant l'architecture sous-jacente est juste Intel, alors pourquoi le shell graphique n'est-il pas une bibliothèque de plus?
Nick Pierpoint
8
Deux raisons. D'abord, c'est plus qu'un simple shell graphique. C'est une couche entière au-dessus d'Unix, sur laquelle Apple travaille depuis des années. Deuxièmement, le code n'est pas disponible. Il faudrait donc le réécrire à partir de zéro. Apple pourrait probablement le faire en peu de temps, mais il n'y a aucune raison pour eux de le faire.
KeithB
1
Donc ... pour Apple au moins, il n'y a pas vraiment de problème technique - ils pourraient migrer OS-X pour fonctionner sur Linux relativement facilement car ils l'ont déjà sous UNIX. De toute évidence, un gros problème pour tout le monde car le code est en source fermée et il n'y a pas d'API entièrement publiée. Est-ce un résumé juste?
Nick Pierpoint
3
Nick: Essentiellement, oui. Apple n'a aucun intérêt à déplacer OSX vers une plate-forme Linux; pourquoi devraient-ils le faire lorsqu'ils ont tant investi dans leur plate-forme Darwin open source (la couche BSD) et leurs bibliothèques Cocoa / Core * fermées (ce qui rend OSX vraiment unique). L'ensemble de leur modèle commercial est le caractère unique de l'ensemble de leur plate-forme - matériel et logiciel. Il est CONCEVABLE que quelqu'un puisse tenter de cloner les bibliothèques, mais cela prendrait des décennies à faire, et ne serait probablement jamais correct à cause de tous les appels non documentés qui devraient être répliqués. Et à quelle fin?
John Rudy
4
GNUStep est une implémentation open source de la plupart des bibliothèques de base qui sont maintenant dans OS X, mais Apple en a ajouté de nombreuses depuis lors, donc le portage n'est toujours pas aussi simple: wiki.gnustep.org/index.php/Cocoa
TRS-80
2

Par applications spécifiques à Apple, entendez-vous des applications GUI? Une fois que vous vous déplacez au-dessus de la ligne de commande, il existe des API spécifiques à Apple pour tout (graphiques, sons, etc.) qui ne sont pas prises en charge sous Linux, vous ne pouvez donc pas facilement porter des applications.

marque
la source
1

La couche graphique n'est pas du tout la même. OS X utilise un cadre graphique propriétaire, linux utilise X (X11 / X.org)

Presque toutes les applications natives OS X utilisent des cadres tels que Cocoa, CoreAnimation et ainsi de suite, qui ne sont disponibles que sur OS X.

Par exemple, supposons que vous ayez une application qui stocke un mot de passe pour l'utilisateur - sur OS X, cela utiliserait son système de trousseau et les API pertinentes. Si vous deviez porter cela sur Linux, il n'y a pas d'équivalent direct, vous devrez donc réimplémenter toute cette fonctionnalité. C'est une toute petite fonctionnalité qui nécessiterait une réécriture importante.

Si vous écrivez votre application à l'aide d'une bibliothèque d'interfaces graphiques comme GTK, Qt ou wxWidgets, le portage sera beaucoup plus facile (ou «possible») - mais les systèmes d'exploitation sont toujours très différents en termes d'interface utilisateur (par exemple, OS X utilise une barre de menus séparée, alors que Linux a tendance à avoir sa barre de menus pour chaque fenêtre)

L'un des meilleurs ports multiplateformes que j'ai vus est Transmission , qui implémente ses principales fonctionnalités en tant que bibliothèque (qui contient le moins de code spécifique à la plate-forme possible), puis crée des interfaces graphiques natives pour chaque plate-forme, séparément. Cela signifie que chaque port partage beaucoup de code, mais tous ont de bonnes interfaces natives (plutôt qu'une interface unique qui s'intègre bien sous Linux, mais qui n'est pas à sa place sous OS X, ou vice versa)

Il existe un projet appelé Cocotron qui "vise à implémenter une API Objective-C multiplateforme similaire à celle décrite par la documentation Cocoa d'Apple Inc." qui pourrait potentiellement faciliter le portage, mais il semble y avoir très peu d'activité ces derniers temps (le dernier article de blog date de décembre 2008)

dbr
la source
1

Parce que la plupart des applications dépendent de bien plus que du processeur et de l'architecture sous-jacente de la machine sur laquelle ils s'exécutent. Ils dépendent également des boîtes à outils de l'interface utilisateur et d'autres bibliothèques spécifiques à la plate-forme.

Kent Boogaart
la source