ne me dites pas que libmetacity-private0a est utilisé par 1000 paquets différents.
Bah non mais si on commence à prendre des bibliothèques de plus bas niveau genre la glibc, voir même d'un niveau un peu plus haut genre Qt, si tu commences à avoir besoin de 4 versions de glibc ou de 12 version de Qt ça va commencer à chiffrer.
L'avantage des bibliothèques partagées c'est que ça oblige chaque projet qui utilise telle bibliothèque à suivre un peu le mouvement en adaptant son code. Si on commence à tout mettre en statique ça risque d'aller loin... Non seulement au niveau espace et mémoire mais aussi poser des problèmes de sécurité comme ça a déjà été dit ici.
Un projet utilise bib-1.0, on découvre une faille dans cette bibliothèque qui est corrigée dans bib-1.1, si le projet reste sur bib-1.0 c'est à lui de rétro-porter le fix, donc il se retrouve à maintenir une bibliothèque en plus de l'application proprement dite (au lieu de modifier son application pour suivre l'API qui a (peut-être) évoluée). Vu qu'un projet peut reposer sur 5 ou 6 bibliothèques c'est pas dur de comprendre que ce n'est pas vraiment viable sur le long terme.
[^] # Re: C'est plus facile de travailler salement...
Posté par Marotte ⛧ . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 7.
Bah non mais si on commence à prendre des bibliothèques de plus bas niveau genre la glibc, voir même d'un niveau un peu plus haut genre Qt, si tu commences à avoir besoin de 4 versions de glibc ou de 12 version de Qt ça va commencer à chiffrer.
L'avantage des bibliothèques partagées c'est que ça oblige chaque projet qui utilise telle bibliothèque à suivre un peu le mouvement en adaptant son code. Si on commence à tout mettre en statique ça risque d'aller loin... Non seulement au niveau espace et mémoire mais aussi poser des problèmes de sécurité comme ça a déjà été dit ici.
Un projet utilise bib-1.0, on découvre une faille dans cette bibliothèque qui est corrigée dans bib-1.1, si le projet reste sur bib-1.0 c'est à lui de rétro-porter le fix, donc il se retrouve à maintenir une bibliothèque en plus de l'application proprement dite (au lieu de modifier son application pour suivre l'API qui a (peut-être) évoluée). Vu qu'un projet peut reposer sur 5 ou 6 bibliothèques c'est pas dur de comprendre que ce n'est pas vraiment viable sur le long terme.