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
Le 10.07.2022 Í 21:47 Stéphane CARPENTIER a écrit:
Le 10-07-2022, Matthieu a écrit :
Le 10.07.2022 Í 09:06 Stéphane CARPENTIER a écrit:
C'est un choix, mais qui est imposé aussi par des contraintes qui ne sont pas les mêmes qu'il y a trente ans.
C'est lÍ o͹ l'argumentation devient discutable, puisque si l'utilisation de librairies partagées était, comme tu le dis, lié uniquement au type de technologie, alors aujourd'hui tout le monde ferait pareil.
Je parle de contraintes qui évoluent. Et tout le monde n'évolue pas au même rythme. Et tout le monde n'a pas forcément trouvé toutes les réponses. Et tout le monde ne veut pas faire pareil.
Il n'y a pas d'évolution en ce qui concerne l'utilisation des librairies dynamiques. Elles étaient utilisé sur SysV dans le temps, et le sont sur Linux aujourd'hui. Elles n'étaient pas utilisées sous DOS, ni Windows 3.11 et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système). Je le répète - c'est juste un choix d'architecture. Argumenté par des principes théoriques bien sÍ»r, mais un choix. Tu dis: "Les développeurs ont dÍ» prendre en compte ces contraintes et tu ne sembles pas le comprendre." "un choix imposé par des contraintes" "des contraintes qui évoluent" Ben non, la réalité montre clairement que c'est juste un choix. Un choix relativement figé dans le temps d'ailleurs, donc indépendant des "contraintes" que tu mentionnes. Je dirais même que c'est un choix philosophique plus que technique, surtout aujourd'hui. Maintenant, est-ce un bon choix ou un mauvais choix? La chose est discutable. Dans certains cas c'est un choix intéressant. Dans bien d'autres, c'est surtout un handicap. Matthieu
Le 10.07.2022 Í 21:47 Stéphane CARPENTIER a écrit:
Le 10-07-2022, Matthieu <matthieu@x.localhost> a écrit :
> Le 10.07.2022 Í 09:06 Stéphane CARPENTIER a écrit:
>> C'est un choix, mais qui est imposé aussi par des contraintes qui
>> ne sont pas les mêmes qu'il y a trente ans.
>
> C'est lÍ o͹ l'argumentation devient discutable, puisque si
> l'utilisation de librairies partagées était, comme tu le dis, lié
> uniquement au type de technologie, alors aujourd'hui tout le monde
> ferait pareil.
Je parle de contraintes qui évoluent. Et tout le monde n'évolue pas au
même rythme. Et tout le monde n'a pas forcément trouvé toutes les
réponses. Et tout le monde ne veut pas faire pareil.
Il n'y a pas d'évolution en ce qui concerne l'utilisation des
librairies dynamiques. Elles étaient utilisé sur SysV dans le temps, et
le sont sur Linux aujourd'hui. Elles n'étaient pas utilisées sous DOS,
ni Windows 3.11 et ne le sont toujours pas sous Windows aujourd'hui
(mise Í part pour les APIs système).
Je le répète - c'est juste un choix d'architecture. Argumenté par des
principes théoriques bien sÍ»r, mais un choix.
Tu dis:
"Les développeurs ont dÍ» prendre en compte ces contraintes et tu ne
sembles pas le comprendre."
"un choix imposé par des contraintes"
"des contraintes qui évoluent"
Ben non, la réalité montre clairement que c'est juste un choix. Un choix
relativement figé dans le temps d'ailleurs, donc indépendant des
"contraintes" que tu mentionnes. Je dirais même que c'est un choix
philosophique plus que technique, surtout aujourd'hui.
Maintenant, est-ce un bon choix ou un mauvais choix? La chose est
discutable. Dans certains cas c'est un choix intéressant. Dans bien
d'autres, c'est surtout un handicap.
Le 10.07.2022 Í 21:47 Stéphane CARPENTIER a écrit:
Le 10-07-2022, Matthieu a écrit :
Le 10.07.2022 Í 09:06 Stéphane CARPENTIER a écrit:
C'est un choix, mais qui est imposé aussi par des contraintes qui ne sont pas les mêmes qu'il y a trente ans.
C'est lÍ o͹ l'argumentation devient discutable, puisque si l'utilisation de librairies partagées était, comme tu le dis, lié uniquement au type de technologie, alors aujourd'hui tout le monde ferait pareil.
Je parle de contraintes qui évoluent. Et tout le monde n'évolue pas au même rythme. Et tout le monde n'a pas forcément trouvé toutes les réponses. Et tout le monde ne veut pas faire pareil.
Il n'y a pas d'évolution en ce qui concerne l'utilisation des librairies dynamiques. Elles étaient utilisé sur SysV dans le temps, et le sont sur Linux aujourd'hui. Elles n'étaient pas utilisées sous DOS, ni Windows 3.11 et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système). Je le répète - c'est juste un choix d'architecture. Argumenté par des principes théoriques bien sÍ»r, mais un choix. Tu dis: "Les développeurs ont dÍ» prendre en compte ces contraintes et tu ne sembles pas le comprendre." "un choix imposé par des contraintes" "des contraintes qui évoluent" Ben non, la réalité montre clairement que c'est juste un choix. Un choix relativement figé dans le temps d'ailleurs, donc indépendant des "contraintes" que tu mentionnes. Je dirais même que c'est un choix philosophique plus que technique, surtout aujourd'hui. Maintenant, est-ce un bon choix ou un mauvais choix? La chose est discutable. Dans certains cas c'est un choix intéressant. Dans bien d'autres, c'est surtout un handicap. Matthieu
Thierry P
Le 11/07/2022 Matthieu écrivait :
Il n'y a pas d'évolution en ce qui concerne l'utilisation des librairies dynamiques.
le bon terme est "bibliothèque", traduction de "library"
Le 11/07/2022 Matthieu <matthieu@x.localhost> écrivait :
Il n'y a pas d'évolution en ce qui concerne l'utilisation des
librairies dynamiques.
le bon terme est "bibliothèque", traduction de "library"
et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système).
GNI ?
Ç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"? 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. Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques. Linux/BSD sont Í l'opposé complet. Matthieu
Le 11.07.2022 Í 12:21 tTh a écrit:
On 7/11/22 07:18, Matthieu wrote:
> et ne le sont toujours pas sous Windows aujourd'hui
> (mise Í part pour les APIs système).
GNI ?
Ç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"? 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.
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas
très propre installait une DLL discrètement dans le répertoire système,
mais c'est des cas anecdotiques.
et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système).
GNI ?
Ç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"? 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. Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques. Linux/BSD sont Í l'opposé complet. Matthieu
Matthieu
Le 11.07.2022 Í 09:32 Nicolas George a écrit:
Matthieu , dans le message <tagbr9$622$, a écrit :
Elles n'étaient pas utilisées sous DOS, ni Windows 3.11 et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système).
Ce qui est bien, avec les incompétents qui étalent leur ignorance, c'est quand ils font des affirmations aussi faciles Í vérifier.
Tu n'as manifestement pas compris les échanges, ce qui te pousse Í cracher gratuitement sur autrui sans aucune forme d'argumentaire du haut de tes trois hello world. Ça ne m'étonne guère venant de toi, Í ce stade cela devient comique. Matthieu
Le 11.07.2022 Í 09:32 Nicolas George a écrit:
Matthieu , dans le message <tagbr9$622$2@gioia.aioe.org>, a écrit :
> Elles n'étaient pas utilisées sous
> DOS,
> ni Windows 3.11 et ne le sont toujours pas sous Windows aujourd'hui
> (mise Í part pour les APIs système).
Ce qui est bien, avec les incompétents qui étalent leur ignorance,
c'est quand ils font des affirmations aussi faciles Í vérifier.
Tu n'as manifestement pas compris les échanges, ce qui te pousse Í
cracher gratuitement sur autrui sans aucune forme d'argumentaire du
haut de tes trois hello world. Ça ne m'étonne guère venant de toi, Í ce
stade cela devient comique.
Matthieu , dans le message <tagbr9$622$, a écrit :
Elles n'étaient pas utilisées sous DOS, ni Windows 3.11 et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système).
Ce qui est bien, avec les incompétents qui étalent leur ignorance, c'est quand ils font des affirmations aussi faciles Í vérifier.
Tu n'as manifestement pas compris les échanges, ce qui te pousse Í cracher gratuitement sur autrui sans aucune forme d'argumentaire du haut de tes trois hello world. Ça ne m'étonne guère venant de toi, Í ce stade cela devient comique. Matthieu
Marc SCHAEFER
Matthieu 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. 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é.
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques. Linux/BSD sont Í l'opposé complet.
Sauf avec l'utilisation de logiciels empaquetés de type Flatpak ou autre, o͹ les problèmes de mises Í jour, de sécurité et d'économicité mentionnés ci-dessus sont légions. EN CONCLUSION: Je crois que la problématique généralisée c'est de la question de l'administration système, de qui la fait, et dans quelles circonstances. Il faut définir ce que l'on veut, et utiliser ensuite la méthode qui convient. 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.
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.
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é.
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas
très propre installait une DLL discrètement dans le répertoire système,
mais c'est des cas anecdotiques.
Linux/BSD sont Í l'opposé complet.
Sauf avec l'utilisation de logiciels empaquetés de type Flatpak ou
autre, o͹ les problèmes de mises Í jour, de sécurité et d'économicité
mentionnés ci-dessus sont légions.
EN CONCLUSION:
Je crois que la problématique généralisée c'est de la question de
l'administration système, de qui la fait, et dans quelles circonstances.
Il faut définir ce que l'on veut, et utiliser ensuite la méthode qui
convient.
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.
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. 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é.
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques. Linux/BSD sont Í l'opposé complet.
Sauf avec l'utilisation de logiciels empaquetés de type Flatpak ou autre, o͹ les problèmes de mises Í jour, de sécurité et d'économicité mentionnés ci-dessus sont légions. EN CONCLUSION: Je crois que la problématique généralisée c'est de la question de l'administration système, de qui la fait, et dans quelles circonstances. Il faut définir ce que l'on veut, et utiliser ensuite la méthode qui convient. 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.
Marc SCHAEFER
Matthieu 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. Ou alors il faut compter sur des méthodes ad-hoc de mise Í jour de chacun de ces logiciels? 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é.
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques. Linux/BSD sont Í l'opposé complet.
Sauf avec l'utilisation de logiciels empaquetés de type Flatpak ou autre, o͹ les problèmes de mises Í jour, de sécurité et d'économicité mentionnés ci-dessus sont légions. EN CONCLUSION: Je crois que la problématique généralisée c'est de la question de l'administration système, de qui la fait, et dans quelles circonstances. Il faut définir ce que l'on veut, et utiliser ensuite la méthode qui convient. 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.
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. Ou alors il faut compter sur des méthodes ad-hoc de mise Í jour
de chacun de ces logiciels?
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é.
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas
très propre installait une DLL discrètement dans le répertoire système,
mais c'est des cas anecdotiques.
Linux/BSD sont Í l'opposé complet.
Sauf avec l'utilisation de logiciels empaquetés de type Flatpak ou
autre, o͹ les problèmes de mises Í jour, de sécurité et d'économicité
mentionnés ci-dessus sont légions.
EN CONCLUSION:
Je crois que la problématique généralisée c'est de la question de
l'administration système, de qui la fait, et dans quelles circonstances.
Il faut définir ce que l'on veut, et utiliser ensuite la méthode qui
convient.
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.
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. Ou alors il faut compter sur des méthodes ad-hoc de mise Í jour de chacun de ces logiciels? 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é.
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques. Linux/BSD sont Í l'opposé complet.
Sauf avec l'utilisation de logiciels empaquetés de type Flatpak ou autre, o͹ les problèmes de mises Í jour, de sécurité et d'économicité mentionnés ci-dessus sont légions. EN CONCLUSION: Je crois que la problématique généralisée c'est de la question de l'administration système, de qui la fait, et dans quelles circonstances. Il faut définir ce que l'on veut, et utiliser ensuite la méthode qui convient. 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.
tTh
On 7/11/22 12:45, Matthieu wrote:
Le 11.07.2022 Í 12:21 tTh a écrit:
On 7/11/22 07:18, Matthieu wrote:
et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système).
GNI ?
Ç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"?
Non, ça ne m'arrive jamais, je n'utilise plus windows depuis 95. mais on retrouve exactement le même souci avec Linux.
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...
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques.
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. xpost + foutou -- +------------------------------------------------------------------+ | https://framalibre.org/content/tetalab | +------------------------------------------------------------------+
On 7/11/22 12:45, Matthieu wrote:
Le 11.07.2022 Í 12:21 tTh a écrit:
On 7/11/22 07:18, Matthieu wrote:
et ne le sont toujours pas sous Windows aujourd'hui
(mise Í part pour les APIs système).
GNI ?
Ç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"?
Non, ça ne m'arrive jamais, je n'utilise plus windows
depuis 95. mais on retrouve exactement le même souci
avec Linux.
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...
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas
très propre installait une DLL discrètement dans le répertoire système,
mais c'est des cas anecdotiques.
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.
et ne le sont toujours pas sous Windows aujourd'hui (mise Í part pour les APIs système).
GNI ?
Ç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"?
Non, ça ne m'arrive jamais, je n'utilise plus windows depuis 95. mais on retrouve exactement le même souci avec Linux.
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...
Il peut (ou pouvait) y avoir quelques vagues cas o͹ un programme pas très propre installait une DLL discrètement dans le répertoire système, mais c'est des cas anecdotiques.
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. xpost + foutou -- +------------------------------------------------------------------+ | https://framalibre.org/content/tetalab | +------------------------------------------------------------------+
Eric Masson
Matthieu writes: 'Lut,
Ç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. Par exemple pour VC++ https://docs.microsoft.com/fr-fr/cpp/windows/latest-supported-vc-redist?view=msvc-170
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.
C'est un choix des développeurs, probablement par facilité ou praticité, Í la AppImage, car le SDK fournit des mécanismes plus évolués pour la résolution des dépendances https://github.com/microsoft/WindowsAppSDK/blob/main/specs/dynamicdependencies/DynamicDependencies.md 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. -- en effet, j'ai fait une erreu. (...) Desoler -+- RV in Guide du Neneu Usenet : Tout le trompe peut se monder -+-
Matthieu <matthieu@x.localhost> writes:
'Lut,
Ç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.
Par exemple pour VC++
https://docs.microsoft.com/fr-fr/cpp/windows/latest-supported-vc-redist?view=msvc-170
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.
C'est un choix des développeurs, probablement par facilité ou praticité,
Í la AppImage, car le SDK fournit des mécanismes plus évolués pour la
résolution des dépendances
https://github.com/microsoft/WindowsAppSDK/blob/main/specs/dynamicdependencies/DynamicDependencies.md
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.
--
en effet, j'ai fait une erreu. (...) Desoler
-+- RV in Guide du Neneu Usenet : Tout le trompe peut se monder -+-
Ç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. Par exemple pour VC++ https://docs.microsoft.com/fr-fr/cpp/windows/latest-supported-vc-redist?view=msvc-170
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.
C'est un choix des développeurs, probablement par facilité ou praticité, Í la AppImage, car le SDK fournit des mécanismes plus évolués pour la résolution des dépendances https://github.com/microsoft/WindowsAppSDK/blob/main/specs/dynamicdependencies/DynamicDependencies.md 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. -- en effet, j'ai fait une erreu. (...) Desoler -+- RV in Guide du Neneu Usenet : Tout le trompe peut se monder -+-
