L'approche a beau être très intéressante, et à le mérité d'apporter une réponse dans certains cas mais elle ne répond pas au véritable problème: avoir des API/ABI/Spécification durables. Même si l'idée est intéressante sur le papier elle abouti à une multiplication des runtimes. Mettons que j'ai une application qui cesse d'être maintenue, dois je garder un snapshot d'une distribution compatible? Que ce passe t'il si j'ai une vingtaine ou une cinquantaine d'application non maintenues? Dois je me retrouver avec autant de snapshots? On va finir par avoir sur chaque machine la collection complète de toutes les révisions d'une distribution majeure.
Et même en le faisant cela n'empêcherait pas certaines incompatibilités. Mettons que sur ma machine, ma carte graphique requiert des drivers recents qui eux ont besoin de biblothèques récentes (libY.so). Mettons également que je souhaite faire tourner une application OpenGL vieille de 10 ans ne fonctionnant qu'avec une version précise (et ancienne) de cette même libY.so . Il n'est pas possible (tout au moins avec le chargeur dynamique GNU) de charger en mémoire deux versions d'une même bibliothèque avec même nom de fichier et même SONAME.
Fournir une application avec ces dépendances est une bonne idée (d'ailleurs déjà largement exploitée) mais pour être rellement fonctionelle il faut pouvoir faire tourner l'application dans le même environnement que celui pour lequel elle a été conçue. Ceci inclus même les composant les plus fondamentaux de l'OS que sont la libc, X, ... . Il n'y a donc pas d'autre choix que de faire tourner chaque (groupe d') application dans une machine virtuelle. Ca tombe bien, Linux est bon dans le domaine.
Il n'en reste pas moins que même si la solution peut être viable, elle demande quand même une multiplication des runtimes. Se forcer a avoir des API/ABI durables est certes plus contraignant mais plus simple sur le long terme.
# De la dureté des diamants ou l'importance de la spécification d'interfaces.
Posté par GTof . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 6.
L'approche a beau être très intéressante, et à le mérité d'apporter une réponse dans certains cas mais elle ne répond pas au véritable problème: avoir des API/ABI/Spécification durables. Même si l'idée est intéressante sur le papier elle abouti à une multiplication des runtimes. Mettons que j'ai une application qui cesse d'être maintenue, dois je garder un snapshot d'une distribution compatible? Que ce passe t'il si j'ai une vingtaine ou une cinquantaine d'application non maintenues? Dois je me retrouver avec autant de snapshots? On va finir par avoir sur chaque machine la collection complète de toutes les révisions d'une distribution majeure.
Et même en le faisant cela n'empêcherait pas certaines incompatibilités. Mettons que sur ma machine, ma carte graphique requiert des drivers recents qui eux ont besoin de biblothèques récentes (libY.so). Mettons également que je souhaite faire tourner une application OpenGL vieille de 10 ans ne fonctionnant qu'avec une version précise (et ancienne) de cette même libY.so . Il n'est pas possible (tout au moins avec le chargeur dynamique GNU) de charger en mémoire deux versions d'une même bibliothèque avec même nom de fichier et même SONAME.
Fournir une application avec ces dépendances est une bonne idée (d'ailleurs déjà largement exploitée) mais pour être rellement fonctionelle il faut pouvoir faire tourner l'application dans le même environnement que celui pour lequel elle a été conçue. Ceci inclus même les composant les plus fondamentaux de l'OS que sont la libc, X, ... . Il n'y a donc pas d'autre choix que de faire tourner chaque (groupe d') application dans une machine virtuelle. Ca tombe bien, Linux est bon dans le domaine.
Il n'en reste pas moins que même si la solution peut être viable, elle demande quand même une multiplication des runtimes. Se forcer a avoir des API/ABI durables est certes plus contraignant mais plus simple sur le long terme.