Pourquoi les «gros binaires» ne sont-ils pas plus largement utilisés pour les applications multiplateformes?


27

Pour autant que je sache, les soi-disant "gros binaires" - des fichiers exécutables qui contiennent du code machine pour plusieurs systèmes - ne sont vraiment utilisés que sur les PC Apple, et même là, il semble qu'ils ne les ont utilisés que parce qu'ils avaient besoin de passer de PowerPC à x86.

De nos jours, beaucoup de logiciels sont multiplates-formes, et il semble que créer un seul gros binaire serait à bien des égards plus simple que de garder une trace d'une douzaine de téléchargements différents pour chaque combinaison de système d'exploitation et d'architecture, sans parler de la transmission au client lequel il veut.

Je peux proposer de nombreuses suppositions pour expliquer pourquoi cette approche n'a jamais pris, par exemple:

  • Un manque d'outils de compilation croisée rendant les binaires multi-OS irréalisables
  • Vous devez quand même tester le code sur chaque système d'exploitation, vous devez donc déjà avoir des systèmes qui peuvent compiler en mode natif pour chaque système d'exploitation
  • Apparemment, les programmes 32 bits "fonctionnent juste" sur les machines 64 bits déjà
  • La liaison dynamique fonctionne différemment sur chaque système d'exploitation, donc une «bibliothèque de graisse» peut ne pas fonctionner même si une «application de graisse»

Mais comme je travaille toujours avec une bibliothèque ou un framework qui me cache tous ces détails spécifiques au système d'exploitation et à l'architecture, je ne sais pas à quel point tout cela est vrai, ou s'il y a encore plus de problèmes, je ne sais pas à propos. Alors, quelles sont les véritables raisons pour lesquelles les binaires fat ne sont généralement pas utilisés pour créer des logiciels multi-architecture et / ou multi-OS? (en dehors d'Apple)


5
Y a-t-il un problème grave que cela résoudrait? Lorsque je vais sur la page de téléchargement des principales applications multiplateformes, ils détectent automatiquement le système d'exploitation que j'utilise et me dirigent dans la bonne direction. Les utilisateurs de Linux ont des gestionnaires de packages. Il me semble que tout cela ne ferait que gonfler les tailles de téléchargement.
Doval

4
Je ne connais pas grand-chose aux gros binaires, mais n'ont-ils pas besoin du support du système d'exploitation (en particulier du chargeur)? Ensuite, je ne vois pas l'intérêt du "logiciel multi-OS" en particulier, car il n'y a aucun moyen que les fournisseurs de système d'exploitation s'accordent sur un format interopérable.

7
Parce que nous avons du code octet et des machines virtuelles qui résolvent mieux ce problème.
Robert Harvey

2
Je me demande, est-il même possible de créer un fichier exécutable polyglotte qui fonctionne à la fois sous Windows et certains * NIX?
aaaaaaaaaaaa

2
Pour mémoire, les binaires fat datent de la transition 68k -> PPC, pas de la transition PPC -> x86.
Mark

Réponses:


9

Une approche binaire grasse est plus logique si:

  1. Les deux architectures coexistent sur le même système
  2. Tout le reste est plus ou moins le même pour toutes les architectures

C'est pourquoi ils ne sont pas utilisés pour le code multiplateforme (les deux critères ne s'appliquent pas), ou pour prendre en charge différentes distributions Linux avec un seul binaire (1. ne s'applique pas, 2. s'applique dans une certaine mesure).

Sous Linux, les deux critères s'appliqueraient toujours si vous souhaitez prendre en charge à la fois 32 et 64 bits sur une seule distribution Linux . Mais pourquoi s'embêter, si vous devez déjà supporter plusieurs distributions?

Sous Windows , la transition de 16 bits à 32 bits s'est produite initialement avec l'introduction de Windows NT, qui constituait une déviation majeure par rapport au monde Windows 16 bits à bien des égards (mémoire virtuelle, contrôle d'accès multi-utilisateurs, changements d'API ...). Avec tous ces changements, il valait mieux garder les mondes 32 et 16 bits séparés. NT avait déjà le concept de «sous-systèmes» prenant en charge différents «personae» d'OS (Win32, POSIX), donc faire de Win16 un troisième sous-système était un choix simple.

La transition de Win32 à Win64 n'a pas impliqué de changements majeurs similaires, mais Microsoft a quand même utilisé une approche similaire, probablement parce qu'elle a été éprouvée et essayée.


11

La logistique de répartition par âge d'Internet décourage les binaires gras de deux manières:

  1. Le point de vente n'implique pas de biens physiques et favorise donc moins de références comme c'est le cas lorsque les produits se disputent l'espace de vente au détail et que les clients ont des possibilités limitées de faire un achat.

  2. Les coûts de la bande passante favorisent la livraison du minimum de bits nécessaires pour un progiciel particulier. L'expédition d'un gros binaire dans le fil dégrade l'expérience client et l'efficacité de l'infrastructure du vendeur.

Les gros fichiers binaires avaient plus de sens lorsque le logiciel était emballé sous forme de support physique.


1
Pour les déploiements de logiciels, le coût de la bande passante est de nos jours presque sans conséquence. Si c'est toujours un problème, attendez 5 minutes de plus.
Robert Harvey

2
@RobertHarvey, mais ce sont 5 minutes, je préfère ne pas attendre.
Arturo Torres Sánchez

2

Une partie des raisons pour lesquelles les binaires fat n'ont pas réussi est qu'il y a plus que les spécifications ABI et processeur (en fait, le jeu d'instructions ) pour invalider un exécutable binaire. Un exécutable binaire dépend souvent beaucoup d'autres ressources, en particulier des bibliothèques dynamiques (voir l' enfer DLL ), des services externes (pensez aux SGBD comme PostGreSQL ....), de la configuration du système (par exemple l'emplacement des fichiers de configuration sous /etc/Linux), etc. . etc....

Juste pour Linux / x86-64, il est en pratique difficile de faire un exécutable binaire capable de s'exécuter sur toutes les distributions Linux (car il est souvent lié à des versions spécifiques de libcou de libstdc++). FatELF existe mais n'a pas beaucoup de succès.

Même avec un ABI et un jeu d'instructions bien définis, l'optimisation serait différente sur différentes marques de processeur - voir l' indicateur d' -mtune=native optimisation x86 de GCC .

Apple a réussi en partie à avoir des binaires gras uniquement parce qu'ils fournissent un écosystème très fermé de ressources informatiques.

Le logiciel libre est un autre moyen de résoudre votre problème de portabilité: si une application est un logiciel libre (soigneusement codé pour la portabilité), il est assez facilement porté sur des systèmes similaires. Et même si le code source d'origine ne fonctionne pas comme prévu sur votre système, vous pouvez l'adapter (ou payer quelqu'un pour faire le travail) généralement assez facilement (bien sûr, un logiciel gratuit lié à un système d'exploitation ou un ABI ou un processeur particulier n'est pas facile à port, vous paierez plus d'efforts pour cela). Et des normes comme POSIX ou Linux Standard Base aident également.

Vous pouvez payer (ou demander) à quelqu'un de porter un logiciel (gratuit) avec le code source disponible, mais il n'est pas réaliste de porter un exécutable binaire.

Enfin, plusieurs frameworks existent pour faciliter le portage sur plusieurs systèmes d'exploitation (à condition que le code source soit disponible), par exemple Qt & POCO .

Même l'utilisation d'un bytecode bien spécifié comme la JVM n'est pas toujours une garantie de portabilité: certaines applications Java sont bien connues pour ne pas être portables (par exemple parce qu'elles attendent une hiérarchie de fichiers et des noms particuliers).

BTW, les systèmes informatiques sont probablement beaucoup moins hétérogènes aujourd'hui que dans les années 1980 ou au début des années 1990 (ou à l'ère du mainframe).

Enfin, les gros binaires sont gros: vous dépenserez beaucoup de ressources (temps de construction, bande passante, taille exécutable) pour un problème de portabilité qui pourrait ne pas concerner beaucoup de monde. Souvenez-vous de l'aphorisme: "il n'y a pas de logiciel portable, seulement un logiciel qui a été porté" (sur certains systèmes particuliers).


4
Je conteste l'idée que le fait de rendre le logiciel "gratuit" le rend également facilement portable.
Robert Harvey

3
Cela ne rend pas le logiciel portable, mais cela permet à quelqu'un de consacrer des efforts à le porter sur une autre plate-forme (ce que vous ne pouvez pas faire de manière réaliste si vous n'avez pas accès et le droit de modifier le code source)
Basile Starynkevitch

2
@RobertHarvey il n'y a peut- être pas de lien fondamental en principe, mais il y a plusieurs raisons entièrement pragmatiques pour lesquelles le logiciel libre s'est répandu très largement sur tant de plates-formes et a créé tant d'outils de construction multiplateforme et de chaînes d'outils.
itsbruce

Une application de source fermée qui dépend entièrement de frameworks et de bibliothèques portables et open source sera un peu plus facile à porter sur d'autres plates-formes par le propriétaire de l'application de source fermée. Je dis cela à partir de mon expérience de première main du bonheur après avoir découvert que le "codage au style OpenCV" est tout ce dont vous avez besoin (pour les besoins de traitement d'image). Bien sûr, l'interface graphique nécessite encore d'autres cadres, tels que Qt, etc. (bien que je n'en ai pas l'expérience de première main).
rwong

4
@RobertHarvey Non. Un logiciel gratuit qui est un gâchis absolu pour le porter est toujours un gâchis absolu - vous augmentez simplement la surface dans laquelle vous pourriez attraper quelqu'un qui se soucie de l'utiliser sur une architecture particulière ou un système d'exploitation suffisant pour le porter, ou suggérer un chemin qui pourrait faire porter quelque chose qui ne fait pas saigner les gens.
Tim Post
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.