C'est quand même pas mal, Linux, Í cÍ´té de Windows, c'est même plutÍ´t mieux.
115 réponses
Ghost-Raider
Mises-Í -jour du jour d'aujourd'hui :
https://www.cjoint.com/doc/22_06/LFCnHsVtgk4_2022-06-28-Mises-%C3%A0-jour.png
MS pourrait en prendre de la graine, avec ses mises-Í -jour désordonnées,
ambiguës, mal commentées, mal traduites et pleines de bugs qui seront
corrigés la prochaine fois et en attendant, on rétrograde Í la
mise-Í -jour précédente, si elle est encore lÍ ....
Pour les copies d'écran aussi d'ailleurs. Celles de mon Mint Cinnamon
sont d'une logique parfaite et d'une simplicité enfantine, alors que
celles de Windows 10 sont mal fichues au possible et s'écrasent les unes
les autres si on ne les renomme pas.
Je sais que je prêche des convaincus mais de simples exemples comme
ceux-ci sont particulièrement édifiants.
--
Courrier envoyé par mon top super extra PC Hardware.fr sous Linux Mint
Cinnamon
libmoncul"? La pratique courante est de distribuer soit des applications statiques, soit d'installer toutes les DLLs nécessaires dans le répertoire du programme qui en a besoin, lors de l'installation de celui-ci.
On doit alors constater que les logiciels de mise Í jour automatique doivent scanner l'ensemble des répertoires, y compris utilisateurs, de la machine et des serveurs de fichiers o͹ les logiciels peuvent se trouver, pour remplacer les bibliothèques concernées par ces mises Í jour.
La question est celle-ci: est-il raisonnable de mettre Í jour une bibliothèque sans que cette modification ne soit validé par l'auteur du programme qui l'utilise? Je pense qu'il n'y a pas de réponse évidente et universelle, cela dépend des cas. Ce qui est certain, et je l'ai déjÍ mentionné auparavant, c'est que l'auteur a testé et qualifié son logiciel sur la base d'une version particulière de la bibliothèque. Les évolutions de celle-ci peuvent être sans conséquence sur le programme, mais cela n'a rien de certain. Certains paquets indiquent des limites de versions pour les bibliothèques qu'ils utilisent, d'autres pas, en fonction de l'humeur et de la connaissance de celui qui a généré le paquet pour telle ou telle distribution. Je pense que cette décision devrait plutÍ´t revenir Í l'auteur du logiciel concerné (avec, pourquoi pas, la possibilité pour l'utilisateur de forcer une mise Í jour d'un des composants Í ses risques et périls en cas de motif impérieux).
Ou alors il faut compter sur des méthodes ad-hoc de mise Í jour de chacun de ces logiciels?
Le processus de mise Í jour des logiciels n'était pas vraiment dans le sujet de ce (sous)thread. Mais pour répondre Í la question, je peux dire qu'une méthode qui me semble intéressante est l'approche utilisé par NixOS, déjÍ mentionné par Stéphane un peu plus haut.
On constate aussi qu'aucun partage en mémoire de ces variantes de bibliothèques n'est plus possible (on les appelle des shared-objects, pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas Í l'économicité.
C'est une question de religion car en pratique, sur les machines actuelles, l'impact est insignifiant.
Si on veut système o͹ tout s'installe au marteau et qu'on réinstalle régulièrement, ce n'est pas la même que que si l'on veut tracer les installations et configurations, choisir les logiciels en fonction de critères (logiciel libre ou non, maintenu ou non, dépendant de composants libres ou non) et assurer la maintenabilité sur le long terme. Aucun système ne pourra résoudre Í la fois ces deux objectifs, Í mon avis.
Je pense que tu surcontrastes un petit peu les deux camps. Utiliser des binaires statiques (ou déployer les bibliothèques necessaires avec les logiciels qui les utilisent) ne signifie pas "installer au marteau". Alors oui, si tu fais référence Í Windows je suis d'accord - c'est un foutoir pas possible, mais ce n'est pas le sujet de la discussion, et une des raisons de cet état de fait c'est qu'il n'y a pas de gestionnaire de paquets sous ce système. L'utilisation ou non de bibliothèques partagées n'y est pour rien. Matthieu
Le 11.07.2022 Í 11:02 Marc SCHAEFER a écrit:
Matthieu <matthieu@x.localhost> wrote:
> libmoncul"? La pratique courante est de distribuer soit des
> applications statiques, soit d'installer toutes les DLLs nécessaires
> dans le répertoire du programme qui en a besoin, lors de
> l'installation de celui-ci.
On doit alors constater que les logiciels de mise Í jour automatique
doivent scanner l'ensemble des répertoires, y compris utilisateurs, de
la machine et des serveurs de fichiers o͹ les logiciels peuvent se
trouver, pour remplacer les bibliothèques concernées par ces mises Í
jour.
La question est celle-ci: est-il raisonnable de mettre Í jour une
bibliothèque sans que cette modification ne soit validé par l'auteur du
programme qui l'utilise? Je pense qu'il n'y a pas de réponse évidente et
universelle, cela dépend des cas. Ce qui est certain, et je l'ai déjÍ
mentionné auparavant, c'est que l'auteur a testé et qualifié son
logiciel sur la base d'une version particulière de la bibliothèque. Les
évolutions de celle-ci peuvent être sans conséquence sur le programme,
mais cela n'a rien de certain.
Certains paquets indiquent des limites de versions pour les
bibliothèques qu'ils utilisent, d'autres pas, en fonction de l'humeur
et de la connaissance de celui qui a généré le paquet pour telle ou
telle distribution. Je pense que cette décision devrait plutÍ´t revenir
Í l'auteur du logiciel concerné (avec, pourquoi pas, la possibilité
pour l'utilisateur de forcer une mise Í jour d'un des composants Í ses
risques et périls en cas de motif impérieux).
Ou alors il faut compter sur des méthodes ad-hoc de mise Í jour
de chacun de ces logiciels?
Le processus de mise Í jour des logiciels n'était pas vraiment dans le
sujet de ce (sous)thread. Mais pour répondre Í la question, je peux
dire qu'une méthode qui me semble intéressante est l'approche utilisé
par NixOS, déjÍ mentionné par Stéphane un peu plus haut.
On constate aussi qu'aucun partage en mémoire de ces variantes de
bibliothèques n'est plus possible (on les appelle des shared-objects,
pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas
Í l'économicité.
C'est une question de religion car en pratique, sur les machines
actuelles, l'impact est insignifiant.
Si on veut système o͹ tout s'installe au marteau et qu'on réinstalle
régulièrement, ce n'est pas la même que que si l'on veut tracer les
installations et configurations, choisir les logiciels en fonction de
critères (logiciel libre ou non, maintenu ou non, dépendant de
composants libres ou non) et assurer la maintenabilité sur le long
terme.
Aucun système ne pourra résoudre Í la fois ces deux objectifs, Í mon
avis.
Je pense que tu surcontrastes un petit peu les deux camps. Utiliser des
binaires statiques (ou déployer les bibliothèques necessaires avec les
logiciels qui les utilisent) ne signifie pas "installer au marteau".
Alors oui, si tu fais référence Í Windows je suis d'accord - c'est un
foutoir pas possible, mais ce n'est pas le sujet de la discussion, et
une des raisons de cet état de fait c'est qu'il n'y a pas de
gestionnaire de paquets sous ce système. L'utilisation ou non de
bibliothèques partagées n'y est pour rien.
libmoncul"? La pratique courante est de distribuer soit des applications statiques, soit d'installer toutes les DLLs nécessaires dans le répertoire du programme qui en a besoin, lors de l'installation de celui-ci.
On doit alors constater que les logiciels de mise Í jour automatique doivent scanner l'ensemble des répertoires, y compris utilisateurs, de la machine et des serveurs de fichiers o͹ les logiciels peuvent se trouver, pour remplacer les bibliothèques concernées par ces mises Í jour.
La question est celle-ci: est-il raisonnable de mettre Í jour une bibliothèque sans que cette modification ne soit validé par l'auteur du programme qui l'utilise? Je pense qu'il n'y a pas de réponse évidente et universelle, cela dépend des cas. Ce qui est certain, et je l'ai déjÍ mentionné auparavant, c'est que l'auteur a testé et qualifié son logiciel sur la base d'une version particulière de la bibliothèque. Les évolutions de celle-ci peuvent être sans conséquence sur le programme, mais cela n'a rien de certain. Certains paquets indiquent des limites de versions pour les bibliothèques qu'ils utilisent, d'autres pas, en fonction de l'humeur et de la connaissance de celui qui a généré le paquet pour telle ou telle distribution. Je pense que cette décision devrait plutÍ´t revenir Í l'auteur du logiciel concerné (avec, pourquoi pas, la possibilité pour l'utilisateur de forcer une mise Í jour d'un des composants Í ses risques et périls en cas de motif impérieux).
Ou alors il faut compter sur des méthodes ad-hoc de mise Í jour de chacun de ces logiciels?
Le processus de mise Í jour des logiciels n'était pas vraiment dans le sujet de ce (sous)thread. Mais pour répondre Í la question, je peux dire qu'une méthode qui me semble intéressante est l'approche utilisé par NixOS, déjÍ mentionné par Stéphane un peu plus haut.
On constate aussi qu'aucun partage en mémoire de ces variantes de bibliothèques n'est plus possible (on les appelle des shared-objects, pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas Í l'économicité.
C'est une question de religion car en pratique, sur les machines actuelles, l'impact est insignifiant.
Si on veut système o͹ tout s'installe au marteau et qu'on réinstalle régulièrement, ce n'est pas la même que que si l'on veut tracer les installations et configurations, choisir les logiciels en fonction de critères (logiciel libre ou non, maintenu ou non, dépendant de composants libres ou non) et assurer la maintenabilité sur le long terme. Aucun système ne pourra résoudre Í la fois ces deux objectifs, Í mon avis.
Je pense que tu surcontrastes un petit peu les deux camps. Utiliser des binaires statiques (ou déployer les bibliothèques necessaires avec les logiciels qui les utilisent) ne signifie pas "installer au marteau". Alors oui, si tu fais référence Í Windows je suis d'accord - c'est un foutoir pas possible, mais ce n'est pas le sujet de la discussion, et une des raisons de cet état de fait c'est qu'il n'y a pas de gestionnaire de paquets sous ce système. L'utilisation ou non de bibliothèques partagées n'y est pour rien. Matthieu
Marc SCHAEFER
Matthieu wrote:
La question est celle-ci: est-il raisonnable de mettre Í jour une bibliothèque sans que cette modification ne soit validé par l'auteur du programme qui l'utilise?
S'il s'agit d'une mise Í jour de sécurité, qui ne devrait pas modifier le comportement du logiciel qui l'utilise, oui, évidemment. Dans le cas de Debian, ça marche assez bien: mais il arrive parfois qu'il y ait des régressions, c'est assez rare toutefois. NB: je ne parle que des mises Í jour de sécurité Í la Debian au sein d'une release stable; cela n'a rien Í voir lorsqu'on ajoute des modifications de fonctionnalité, lÍ un cycle de test doit être effectué, et c'est que ce que le `freeze' fait pour les logiciels dans la distribution, et la `release' pour ceux en-dehors.
Matthieu <matthieu@x.localhost> wrote:
La question est celle-ci: est-il raisonnable de mettre Í jour une
bibliothèque sans que cette modification ne soit validé par l'auteur du
programme qui l'utilise?
S'il s'agit d'une mise Í jour de sécurité, qui ne devrait pas modifier
le comportement du logiciel qui l'utilise, oui, évidemment.
Dans le cas de Debian, ça marche assez bien: mais il arrive parfois
qu'il y ait des régressions, c'est assez rare toutefois.
NB: je ne parle que des mises Í jour de sécurité Í la Debian au sein
d'une release stable; cela n'a rien Í voir lorsqu'on ajoute des
modifications de fonctionnalité, lÍ un cycle de test doit être effectué,
et c'est que ce que le `freeze' fait pour les logiciels dans la
distribution, et la `release' pour ceux en-dehors.
La question est celle-ci: est-il raisonnable de mettre Í jour une bibliothèque sans que cette modification ne soit validé par l'auteur du programme qui l'utilise?
S'il s'agit d'une mise Í jour de sécurité, qui ne devrait pas modifier le comportement du logiciel qui l'utilise, oui, évidemment. Dans le cas de Debian, ça marche assez bien: mais il arrive parfois qu'il y ait des régressions, c'est assez rare toutefois. NB: je ne parle que des mises Í jour de sécurité Í la Debian au sein d'une release stable; cela n'a rien Í voir lorsqu'on ajoute des modifications de fonctionnalité, lÍ un cycle de test doit être effectué, et c'est que ce que le `freeze' fait pour les logiciels dans la distribution, et la `release' pour ceux en-dehors.
tTh
On 7/11/22 13:40, Matthieu wrote:
On constate aussi qu'aucun partage en mémoire de ces variantes de bibliothèques n'est plus possible (on les appelle des shared-objects, pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas Í l'économicité.
C'est une question de religion car en pratique, sur les machines actuelles, l'impact est insignifiant.
Pas forcément dans l'embarqué. -- +------------------------------------------------------------------+ | https://framalibre.org/content/tetalab | +------------------------------------------------------------------+
On 7/11/22 13:40, Matthieu wrote:
On constate aussi qu'aucun partage en mémoire de ces variantes de
bibliothèques n'est plus possible (on les appelle des shared-objects,
pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas
Í l'économicité.
C'est une question de religion car en pratique, sur les machines
actuelles, l'impact est insignifiant.
On constate aussi qu'aucun partage en mémoire de ces variantes de bibliothèques n'est plus possible (on les appelle des shared-objects, pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas Í l'économicité.
C'est une question de religion car en pratique, sur les machines actuelles, l'impact est insignifiant.
Pas forcément dans l'embarqué. -- +------------------------------------------------------------------+ | https://framalibre.org/content/tetalab | +------------------------------------------------------------------+
Matthieu
Le 11.07.2022 Í 13:07 tTh a écrit:
La pratique courante est de distribuer soit des applications statiques, soit d'installer toutes les DLLs nécessaires dans le répertoire du programme qui en a besoin, lors de l'installation de celui-ci.
Le cracra habituel, quoi...
Non, ce n'est pas crade. C'est fonctionnel et isolé. Ce qui est crade par contre, c'est de devoir installer Í la main tous les logiciels, avec chacun un installateur différent qui peut potentiellement faire n'importe quoi. Mais de nouveau, ce n'est pas vraiment l'objet de cette discussion.
Par contre, j'ai collaboré avec un développeur d'applications spécifiques, et toute la "logique métier" était dans deux DLL. Les diverses interfaces utilisateur étant codées dans divers langages appelant les fonctions des DLL. Ce qui me semble une bonne approche et contredit ton affirmation.
Je n'ai jamais dit que les DLLs n'existaient pas sous Windows... Ni sous MS-DOS d'ailleurs, puisqu'Í l'époque les overlays étaient déjÍ une forme de code partagé (et un peu plus tard les objet DXE). L'exemple que tu donnes est un cas particulier: une suite d'outils qui exploitent une base de fonctions ou méthodes communes. L'utilisation d'une DLL centrale est une solution possible, pourquoi pas. Cette DLL est cependant distribuée avec les logiciels en question, donc strictement contrÍ´lée par l'auteur de la suite et consistante avec l'ensemble des applicatifs qui l'exploitent. Matthieu
Le 11.07.2022 Í 13:07 tTh a écrit:
La pratique courante est de distribuer soit des
applications statiques, soit d'installer toutes les DLLs nécessaires
dans le répertoire du programme qui en a besoin, lors de
l'installation de celui-ci.
Le cracra habituel, quoi...
Non, ce n'est pas crade. C'est fonctionnel et isolé. Ce qui est crade
par contre, c'est de devoir installer Í la main tous les logiciels,
avec chacun un installateur différent qui peut potentiellement faire
n'importe quoi. Mais de nouveau, ce n'est pas vraiment l'objet de cette
discussion.
Par contre, j'ai collaboré avec un développeur d'applications
spécifiques, et toute la "logique métier" était dans deux DLL.
Les diverses interfaces utilisateur étant codées dans divers
langages appelant les fonctions des DLL. Ce qui me semble une
bonne approche et contredit ton affirmation.
Je n'ai jamais dit que les DLLs n'existaient pas sous Windows... Ni
sous MS-DOS d'ailleurs, puisqu'Í l'époque les overlays étaient déjÍ une
forme de code partagé (et un peu plus tard les objet DXE).
L'exemple que tu donnes est un cas particulier: une suite d'outils qui
exploitent une base de fonctions ou méthodes communes. L'utilisation
d'une DLL centrale est une solution possible, pourquoi pas. Cette DLL
est cependant distribuée avec les logiciels en question, donc
strictement contrÍ´lée par l'auteur de la suite et consistante avec
l'ensemble des applicatifs qui l'exploitent.
La pratique courante est de distribuer soit des applications statiques, soit d'installer toutes les DLLs nécessaires dans le répertoire du programme qui en a besoin, lors de l'installation de celui-ci.
Le cracra habituel, quoi...
Non, ce n'est pas crade. C'est fonctionnel et isolé. Ce qui est crade par contre, c'est de devoir installer Í la main tous les logiciels, avec chacun un installateur différent qui peut potentiellement faire n'importe quoi. Mais de nouveau, ce n'est pas vraiment l'objet de cette discussion.
Par contre, j'ai collaboré avec un développeur d'applications spécifiques, et toute la "logique métier" était dans deux DLL. Les diverses interfaces utilisateur étant codées dans divers langages appelant les fonctions des DLL. Ce qui me semble une bonne approche et contredit ton affirmation.
Je n'ai jamais dit que les DLLs n'existaient pas sous Windows... Ni sous MS-DOS d'ailleurs, puisqu'Í l'époque les overlays étaient déjÍ une forme de code partagé (et un peu plus tard les objet DXE). L'exemple que tu donnes est un cas particulier: une suite d'outils qui exploitent une base de fonctions ou méthodes communes. L'utilisation d'une DLL centrale est une solution possible, pourquoi pas. Cette DLL est cependant distribuée avec les logiciels en question, donc strictement contrÍ´lée par l'auteur de la suite et consistante avec l'ensemble des applicatifs qui l'exploitent. Matthieu
Matthieu
Le 11.07.2022 Í 13:57 tTh a écrit:
On 7/11/22 13:40, Matthieu wrote:
On constate aussi qu'aucun partage en mémoire de ces variantes de bibliothèques n'est plus possible (on les appelle des shared-objects, pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas Í l'économicité.
C'est une question de religion car en pratique, sur les machines actuelles, l'impact est insignifiant.
Pas forcément dans l'embarqué.
Alors tu as un firmware flashé dans le SoC ou sur un support associé. Le souci de mise Í jour partielles de quoi que ce devient tout Í fait hors sujet. Matthieu
Le 11.07.2022 Í 13:57 tTh a écrit:
On 7/11/22 13:40, Matthieu wrote:
>> On constate aussi qu'aucun partage en mémoire de ces variantes de
>> bibliothèques n'est plus possible (on les appelle des
>> shared-objects, pas pour rien, sous Linux et autres OS
>> similaires). Cela ne vise pas Í l'économicité.
>
> C'est une question de religion car en pratique, sur les machines
> actuelles, l'impact est insignifiant.
Pas forcément dans l'embarqué.
Alors tu as un firmware flashé dans le SoC ou sur un support associé.
Le souci de mise Í jour partielles de quoi que ce devient tout Í fait
hors sujet.
On constate aussi qu'aucun partage en mémoire de ces variantes de bibliothèques n'est plus possible (on les appelle des shared-objects, pas pour rien, sous Linux et autres OS similaires). Cela ne vise pas Í l'économicité.
C'est une question de religion car en pratique, sur les machines actuelles, l'impact est insignifiant.
Pas forcément dans l'embarqué.
Alors tu as un firmware flashé dans le SoC ou sur un support associé. Le souci de mise Í jour partielles de quoi que ce devient tout Í fait hors sujet. Matthieu
Matthieu
Le 11.07.2022 Í 11:44 Marc SCHAEFER a écrit:
Matthieu wrote:
La question est celle-ci: est-il raisonnable de mettre Í jour une bibliothèque sans que cette modification ne soit validé par l'auteur du programme qui l'utilise?
S'il s'agit d'une mise Í jour de sécurité, qui ne devrait pas modifier le comportement du logiciel qui l'utilise, oui, évidemment.
Cela fait partie des cas impérieux que je mentionnait tout Í l'heure, bien qu'il soit préférable que cette décision ait été validée par l'éditeur du logiciel lui-même si possible.
Dans le cas de Debian, ça marche assez bien: mais il arrive parfois qu'il y ait des régressions, c'est assez rare toutefois.
Il arrive aussi que certaines bibliothèques disparaissent purement et simplement d'une version (majeure) Í l'autre, ce qui signe la mort de tous les logiciels qui les exploitaient. Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points de vue. Matthieu
Le 11.07.2022 Í 11:44 Marc SCHAEFER a écrit:
Matthieu <matthieu@x.localhost> wrote:
> La question est celle-ci: est-il raisonnable de mettre Í jour une
> bibliothèque sans que cette modification ne soit validé par
> l'auteur du programme qui l'utilise?
S'il s'agit d'une mise Í jour de sécurité, qui ne devrait pas modifier
le comportement du logiciel qui l'utilise, oui, évidemment.
Cela fait partie des cas impérieux que je mentionnait tout Í l'heure,
bien qu'il soit préférable que cette décision ait été validée par
l'éditeur du logiciel lui-même si possible.
Dans le cas de Debian, ça marche assez bien: mais il arrive parfois
qu'il y ait des régressions, c'est assez rare toutefois.
Il arrive aussi que certaines bibliothèques disparaissent purement et
simplement d'une version (majeure) Í l'autre, ce qui signe la mort de
tous les logiciels qui les exploitaient.
Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points
de vue.
La question est celle-ci: est-il raisonnable de mettre Í jour une bibliothèque sans que cette modification ne soit validé par l'auteur du programme qui l'utilise?
S'il s'agit d'une mise Í jour de sécurité, qui ne devrait pas modifier le comportement du logiciel qui l'utilise, oui, évidemment.
Cela fait partie des cas impérieux que je mentionnait tout Í l'heure, bien qu'il soit préférable que cette décision ait été validée par l'éditeur du logiciel lui-même si possible.
Dans le cas de Debian, ça marche assez bien: mais il arrive parfois qu'il y ait des régressions, c'est assez rare toutefois.
Il arrive aussi que certaines bibliothèques disparaissent purement et simplement d'une version (majeure) Í l'autre, ce qui signe la mort de tous les logiciels qui les exploitaient. Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points de vue. Matthieu
Matthieu
Le 11.07.2022 Í 13:25 Eric Masson a écrit:
Ça t'arrive souvent de voir un logiciel Windows refuser de se lancer en disant "nan, faut d'abord installer libzip, libgtk, libtiff et libmoncul"?
En indiquant qu'il faut au préalable avoir installé les libs runtime de l'outil de dev qui a servi Í les compiler, oui.
Les "redistribuables" sont une exceptions, tu as raison oui. À une époque il y avait aussi DirectX pour les jeux (intégré au système depuis, je crois), et éventuellement les codecs. On peut toutefois compter ces exceptions sur les doigts d'une main, ce n'est pas comparable avec les milliers de bibliothèques en tout genre disponibles sous Linux.
La valeur ajoutée des systèmes de packaging des distributions réside justement dans la connaissance des mainteneurs en termes de gestion des dépendances.
La valeur ajoutée est dans l'oeil de celui qui regarde la chose. Je trouve que Guix apporte - sous cet aspect précis - une valeur ajoutée bien supérieure. Matthieu
Le 11.07.2022 Í 13:25 Eric Masson a écrit:
> Ça t'arrive souvent de voir un logiciel Windows refuser de se
> lancer en disant "nan, faut d'abord installer libzip, libgtk,
> libtiff et libmoncul"?
En indiquant qu'il faut au préalable avoir installé les libs runtime
de l'outil de dev qui a servi Í les compiler, oui.
Les "redistribuables" sont une exceptions, tu as raison oui. À une
époque il y avait aussi DirectX pour les jeux (intégré au système
depuis, je crois), et éventuellement les codecs. On peut toutefois
compter ces exceptions sur les doigts d'une main, ce n'est pas
comparable avec les milliers de bibliothèques en tout genre disponibles
sous Linux.
La valeur ajoutée des systèmes de packaging des distributions réside
justement dans la connaissance des mainteneurs en termes de gestion
des dépendances.
La valeur ajoutée est dans l'oeil de celui qui regarde la chose. Je
trouve que Guix apporte - sous cet aspect précis - une valeur ajoutée
bien supérieure.
Ça t'arrive souvent de voir un logiciel Windows refuser de se lancer en disant "nan, faut d'abord installer libzip, libgtk, libtiff et libmoncul"?
En indiquant qu'il faut au préalable avoir installé les libs runtime de l'outil de dev qui a servi Í les compiler, oui.
Les "redistribuables" sont une exceptions, tu as raison oui. À une époque il y avait aussi DirectX pour les jeux (intégré au système depuis, je crois), et éventuellement les codecs. On peut toutefois compter ces exceptions sur les doigts d'une main, ce n'est pas comparable avec les milliers de bibliothèques en tout genre disponibles sous Linux.
La valeur ajoutée des systèmes de packaging des distributions réside justement dans la connaissance des mainteneurs en termes de gestion des dépendances.
La valeur ajoutée est dans l'oeil de celui qui regarde la chose. Je trouve que Guix apporte - sous cet aspect précis - une valeur ajoutée bien supérieure. Matthieu
Marc SCHAEFER
Matthieu wrote:
Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points de vue.
Tout Í fait, et le monde semble s'acheminer vers des installations Í courte durée de vie (j'instancie un conteneur avec des scripts de configuration, je reprends les données; et demain, plutÍ´t que de mettre Í jour, je réinstalle). Dans ce contexte, NixOS, ou tout système de configuration Í courte vie est effectivement utile.
Matthieu <matthieu@x.localhost> wrote:
Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points
de vue.
Tout Í fait, et le monde semble s'acheminer vers des installations Í
courte durée de vie (j'instancie un conteneur avec des scripts de
configuration, je reprends les données; et demain, plutÍ´t que de mettre
Í jour, je réinstalle).
Dans ce contexte, NixOS, ou tout système de configuration Í courte vie
est effectivement utile.
Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points de vue.
Tout Í fait, et le monde semble s'acheminer vers des installations Í courte durée de vie (j'instancie un conteneur avec des scripts de configuration, je reprends les données; et demain, plutÍ´t que de mettre Í jour, je réinstalle). Dans ce contexte, NixOS, ou tout système de configuration Í courte vie est effectivement utile.
Matthieu
Le 11.07.2022 Í 12:32 Marc SCHAEFER a écrit:
Matthieu wrote:
Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points de vue.
Tout Í fait, et le monde semble s'acheminer vers des installations Í courte durée de vie (j'instancie un conteneur avec des scripts de configuration, je reprends les données; et demain, plutÍ´t que de mettre Í jour, je réinstalle). Dans ce contexte, NixOS, ou tout système de configuration Í courte vie est effectivement utile.
Je partage cette bibli--- cet avis pardon. Un autre avantage des conteneurs, c'est que comme ils sont autonomes, on peut prendre un logiciel de 20 ans et le faire tourner de suite. Chose difficile avec le concept de dépendances Í tout un écosystème de librairies interconnectées, o͹ logiciel peut devenir inutilisable du jour au lendemain simplement parce qu'une de ses dépendances a été retiré de la distribution... Matthieu
Le 11.07.2022 Í 12:32 Marc SCHAEFER a écrit:
Matthieu <matthieu@x.localhost> wrote:
> Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout
> points de vue.
Tout Í fait, et le monde semble s'acheminer vers des installations Í
courte durée de vie (j'instancie un conteneur avec des scripts de
configuration, je reprends les données; et demain, plutÍ´t que de
mettre Í jour, je réinstalle).
Dans ce contexte, NixOS, ou tout système de configuration Í courte vie
est effectivement utile.
Je partage cette bibli--- cet avis pardon.
Un autre avantage des conteneurs, c'est que comme ils sont autonomes,
on peut prendre un logiciel de 20 ans et le faire tourner de suite.
Chose difficile avec le concept de dépendances Í tout un écosystème de
librairies interconnectées, o͹ logiciel peut devenir inutilisable du
jour au lendemain simplement parce qu'une de ses dépendances a été
retiré de la distribution...
Je l'ai déjÍ dit avant: il n'y a pas de solution parfaite Í tout points de vue.
Tout Í fait, et le monde semble s'acheminer vers des installations Í courte durée de vie (j'instancie un conteneur avec des scripts de configuration, je reprends les données; et demain, plutÍ´t que de mettre Í jour, je réinstalle). Dans ce contexte, NixOS, ou tout système de configuration Í courte vie est effectivement utile.
Je partage cette bibli--- cet avis pardon. Un autre avantage des conteneurs, c'est que comme ils sont autonomes, on peut prendre un logiciel de 20 ans et le faire tourner de suite. Chose difficile avec le concept de dépendances Í tout un écosystème de librairies interconnectées, o͹ logiciel peut devenir inutilisable du jour au lendemain simplement parce qu'une de ses dépendances a été retiré de la distribution... Matthieu
Marc SCHAEFER
Matthieu wrote:
Un autre avantage des conteneurs, c'est que comme ils sont autonomes, on peut prendre un logiciel de 20 ans et le faire tourner de suite.
Y compris avec ses failles de sécurité: si bien confiné, ça peut être un pis aller temporaire.
Chose difficile avec le concept de dépendances Í tout un écosystème de librairies interconnectées, o͹ logiciel peut devenir inutilisable du jour au lendemain simplement parce qu'une de ses dépendances a été retiré de la distribution...
Mais il ne faut pas oublier que qui dit virtualisation, dit host également. On pourrait souhaiter que ces hosts soient hyper-simplifiés avec très peu de dépendances. Or les solutions de virtualisation peuvent être complexes. Ici par exemple, sur les 6 hosts de mon cloud privé, j'ai du Debian, c'est très confortable d'avoir 5 ans de support sécurité. Et le cloud est réinstallable par scripts. Mais dans les hosts de ce cloud, je réfléchirais Í 2 (ou 50) fois avant d'installer un logiciel propriétaire ou non intégré Í ma distribution ...
Matthieu <matthieu@x.localhost> wrote:
Un autre avantage des conteneurs, c'est que comme ils sont autonomes,
on peut prendre un logiciel de 20 ans et le faire tourner de suite.
Y compris avec ses failles de sécurité: si bien confiné, ça peut être un
pis aller temporaire.
Chose difficile avec le concept de dépendances Í tout un écosystème de
librairies interconnectées, o͹ logiciel peut devenir inutilisable du
jour au lendemain simplement parce qu'une de ses dépendances a été
retiré de la distribution...
Mais il ne faut pas oublier que qui dit virtualisation, dit host
également. On pourrait souhaiter que ces hosts soient hyper-simplifiés
avec très peu de dépendances. Or les solutions de virtualisation
peuvent être complexes.
Ici par exemple, sur les 6 hosts de mon cloud privé, j'ai du Debian,
c'est très confortable d'avoir 5 ans de support sécurité. Et le cloud
est réinstallable par scripts.
Mais dans les hosts de ce cloud, je réfléchirais Í 2 (ou 50) fois avant
d'installer un logiciel propriétaire ou non intégré Í ma distribution
...
Un autre avantage des conteneurs, c'est que comme ils sont autonomes, on peut prendre un logiciel de 20 ans et le faire tourner de suite.
Y compris avec ses failles de sécurité: si bien confiné, ça peut être un pis aller temporaire.
Chose difficile avec le concept de dépendances Í tout un écosystème de librairies interconnectées, o͹ logiciel peut devenir inutilisable du jour au lendemain simplement parce qu'une de ses dépendances a été retiré de la distribution...
Mais il ne faut pas oublier que qui dit virtualisation, dit host également. On pourrait souhaiter que ces hosts soient hyper-simplifiés avec très peu de dépendances. Or les solutions de virtualisation peuvent être complexes. Ici par exemple, sur les 6 hosts de mon cloud privé, j'ai du Debian, c'est très confortable d'avoir 5 ans de support sécurité. Et le cloud est réinstallable par scripts. Mais dans les hosts de ce cloud, je réfléchirais Í 2 (ou 50) fois avant d'installer un logiciel propriétaire ou non intégré Í ma distribution ...
