Hormis le fait qu'os X est contrôlé par une seule entité (apple) :
mac os X met à disposition un "framework" de développement très complet
(le fameux "cocoa" et sa myriade de kit/core associés et Carbon)
du coup, c'est très rare qu'un développeur sur os X ait subitement besoin d'une bibliothèque exotique
quand c'est le cas, il est en effet d'usage de l'intégrer DANS le "bundle" de l'application
(une application os X est un dossier qui peut contenir en plus du binaire des éventuelles bibliothèques, icones, etc)
il arrive donc que des programmes os X intègrent la même bibliothèque populaire parce qu'Apple ne propose rien encore d'équivalent. Un cas classique c'est quand les développeurs veulent imiter un aspect des logiciels d'Apple qu'Apple n'a pas encore standardisé dans os X.
dans les faits c'est rare (cocoa/carbon est tout de même très complet) et d'expérience, je n'ai pas ressenti que les programmes Mac prenaient une taille démentielle en comparaison de ceux de Linux.
Cela dit, si vous en êtes encore à compter les octets, oui os X n'est pas optimisé pour économiser le disque dur, mais conçu pour simplifier la vie des utilisateurs et des développeurs sans pour autant tomber dans un délire à la windows.
il faut bien réaliser qu'apple ,à chaque version d'os X, a agrandit "cocoa" , pour que tous les besoins des créateurs de programmes soient couverts. du coup, les développeurs n'ont pas eu besoin de partir dans le "dll hell" de windows.
un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc
(j'ai utilisé le terme "cocoa" dans son sens le plus large, les puristes sépareront peut être Webkit, webcore , core-data, core-image, core-bidule etc de "cocoa" , mais dans la pratique , le tout forme une plateforme couvrant presque tous les usages ce qui limite le besoin d'une gestion de paquetages provenant de multiples sources)
bref, vla pourquoi os X n'a pas dégénéré en dll hell malgré son manque d'un véritable système de paquetage et dépendance.
[^] # Re: Difficile
Posté par - - . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 6.
mac os X met à disposition un "framework" de développement très complet
(le fameux "cocoa" et sa myriade de kit/core associés et Carbon)
du coup, c'est très rare qu'un développeur sur os X ait subitement besoin d'une bibliothèque exotique
quand c'est le cas, il est en effet d'usage de l'intégrer DANS le "bundle" de l'application
(une application os X est un dossier qui peut contenir en plus du binaire des éventuelles bibliothèques, icones, etc)
il arrive donc que des programmes os X intègrent la même bibliothèque populaire parce qu'Apple ne propose rien encore d'équivalent. Un cas classique c'est quand les développeurs veulent imiter un aspect des logiciels d'Apple qu'Apple n'a pas encore standardisé dans os X.
dans les faits c'est rare (cocoa/carbon est tout de même très complet) et d'expérience, je n'ai pas ressenti que les programmes Mac prenaient une taille démentielle en comparaison de ceux de Linux.
Cela dit, si vous en êtes encore à compter les octets, oui os X n'est pas optimisé pour économiser le disque dur, mais conçu pour simplifier la vie des utilisateurs et des développeurs sans pour autant tomber dans un délire à la windows.
il faut bien réaliser qu'apple ,à chaque version d'os X, a agrandit "cocoa" , pour que tous les besoins des créateurs de programmes soient couverts. du coup, les développeurs n'ont pas eu besoin de partir dans le "dll hell" de windows.
un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc
(j'ai utilisé le terme "cocoa" dans son sens le plus large, les puristes sépareront peut être Webkit, webcore , core-data, core-image, core-bidule etc de "cocoa" , mais dans la pratique , le tout forme une plateforme couvrant presque tous les usages ce qui limite le besoin d'une gestion de paquetages provenant de multiples sources)
bref, vla pourquoi os X n'a pas dégénéré en dll hell malgré son manque d'un véritable système de paquetage et dépendance.