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
OpenOffice.org n'est pas le départ de LibreOffice.
Peux-tu préciser ? Ce n'est pas un fork ?
C'est le résultat d'un désaccord entre Oracle, qui éditait OpenOffice.org, et les développeurs bénévoles. Ceux-ci voulaient nettoyer le code source des lignes inutiles qui s'accumulaient au fil des versions, et qui avaient pour résultat d'alourdir et de ralentir OpenOffice, ce qu'Oracle refusait. D'o͹ l'apparition de LibreOffice, d'abord résultat de ce dégraissage, et qui évolue désormais indépendamment d'OpenOffice. Oracle a ensuite cédé OpenOffice Í la fondation Apache. -- Faͱch
Le 02/07/2022 Í 18:13, Jo Engo a écrit :
OpenOffice.org n'est pas le départ de LibreOffice.
Peux-tu préciser ? Ce n'est pas un fork ?
C'est le résultat d'un désaccord entre Oracle, qui éditait
OpenOffice.org, et les développeurs bénévoles. Ceux-ci voulaient
nettoyer le code source des lignes inutiles qui s'accumulaient au fil
des versions, et qui avaient pour résultat d'alourdir et de ralentir
OpenOffice, ce qu'Oracle refusait.
D'o͹ l'apparition de LibreOffice, d'abord résultat de ce dégraissage, et
qui évolue désormais indépendamment d'OpenOffice.
Oracle a ensuite cédé OpenOffice Í la fondation Apache.
OpenOffice.org n'est pas le départ de LibreOffice.
Peux-tu préciser ? Ce n'est pas un fork ?
C'est le résultat d'un désaccord entre Oracle, qui éditait OpenOffice.org, et les développeurs bénévoles. Ceux-ci voulaient nettoyer le code source des lignes inutiles qui s'accumulaient au fil des versions, et qui avaient pour résultat d'alourdir et de ralentir OpenOffice, ce qu'Oracle refusait. D'o͹ l'apparition de LibreOffice, d'abord résultat de ce dégraissage, et qui évolue désormais indépendamment d'OpenOffice. Oracle a ensuite cédé OpenOffice Í la fondation Apache. -- Faͱch
william
On 2022-07-03, Jo Engo wrote:
Le 02 Jul 2022 21:28:57 GMT, william a écrit :
parapluie / velo et linux / internet ?
Juste que l'on peut très bien utiliser linux sans internet (même y faire des mise Í jour, pourvu qu'on est un support (comme une clé usb et un support internet distant (accessible Í vélo)), mais lÍ ça peut aller trop loin)
Pour avoir utilisé des versions obsolètes de slackware (une époque avec internet trop cher), j'utilisais l'internet de l'école. Et j'ai installé les sources programmes pour "voir" des versions de desktop environment récent. C'etait pas facile de télécharger les dépendances. Alors que pour windows, un simple binaire et il y avait tout dedans.
On 2022-07-03, Jo Engo <yl@icite.fr> wrote:
Le 02 Jul 2022 21:28:57 GMT, william a écrit :
parapluie / velo et linux / internet ?
Juste que l'on peut très bien utiliser linux sans internet (même y faire
des mise Í jour, pourvu qu'on est un support (comme une clé usb et un
support internet distant (accessible Í vélo)), mais lÍ ça peut aller trop
loin)
Pour avoir utilisé des versions obsolètes de slackware (une époque avec
internet trop cher), j'utilisais l'internet de l'école. Et j'ai installé
les sources programmes pour "voir" des versions de desktop environment
récent. C'etait pas facile de télécharger les dépendances.
Alors que pour windows, un simple binaire et il y avait tout dedans.
Juste que l'on peut très bien utiliser linux sans internet (même y faire des mise Í jour, pourvu qu'on est un support (comme une clé usb et un support internet distant (accessible Í vélo)), mais lÍ ça peut aller trop loin)
Pour avoir utilisé des versions obsolètes de slackware (une époque avec internet trop cher), j'utilisais l'internet de l'école. Et j'ai installé les sources programmes pour "voir" des versions de desktop environment récent. C'etait pas facile de télécharger les dépendances. Alors que pour windows, un simple binaire et il y avait tout dedans.
Christophe PEREZ
Le 05 Jul 2022 18:37:06 GMT, william a écrit :
Alors que pour windows, un simple binaire et il y avait tout dedans.
Euh... oui mais non. Il me semble bien que sous Windows, pour ce dont je me souviens, il y avait des dll un peu partout, qui venaient avec chaque logiciel, et écrasaient celles des autres logiciels, d'o͹ de multiples plantages possibles Í chaque fois qu'on installait un nouveau logiciel, sans parler de la multiplication totalement inutile de toutes ces bibliothèques de données. S'il y a bien un argument qui plaide en faveur de Linux, c'est justement celui-ci. Il ne faut pas confondre simplicité et efficacité.
Le 05 Jul 2022 18:37:06 GMT,
william <blop@no.spam> a écrit :
Alors que pour windows, un simple binaire et il y avait tout dedans.
Euh... oui mais non.
Il me semble bien que sous Windows, pour ce dont je me souviens, il y
avait des dll un peu partout, qui venaient avec chaque logiciel, et
écrasaient celles des autres logiciels, d'o͹ de multiples plantages
possibles Í chaque fois qu'on installait un nouveau logiciel, sans
parler de la multiplication totalement inutile de toutes ces
bibliothèques de données.
S'il y a bien un argument qui plaide en faveur de Linux, c'est justement
celui-ci.
Il ne faut pas confondre simplicité et efficacité.
Alors que pour windows, un simple binaire et il y avait tout dedans.
Euh... oui mais non. Il me semble bien que sous Windows, pour ce dont je me souviens, il y avait des dll un peu partout, qui venaient avec chaque logiciel, et écrasaient celles des autres logiciels, d'o͹ de multiples plantages possibles Í chaque fois qu'on installait un nouveau logiciel, sans parler de la multiplication totalement inutile de toutes ces bibliothèques de données. S'il y a bien un argument qui plaide en faveur de Linux, c'est justement celui-ci. Il ne faut pas confondre simplicité et efficacité.
Matthieu
Le 05.07.2022 Í 17:01 Christophe PEREZ a écrit:
Le 05 Jul 2022 18:37:06 GMT, william a écrit :
Alors que pour windows, un simple binaire et il y avait tout dedans.
Euh... oui mais non. Il me semble bien que sous Windows, pour ce dont je me souviens, il y avait des dll un peu partout
Ce n'était/n'est pas la règle je crois, plutÍ´t des exceptions pour des trucs plus ou moins "standard" comme MSVCRT, DirectX etc... Et c'est vrai que ce n'est pas exceptionnellement propre. Il n'en reste que la vaste majorité des programmes Windows se lancent sans dépendances extérieures Í WinAPI. C'est possible sous Linux aussi, via des binaires statiques, mais ce n'est pas la règle. Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques, y lier dynamiquement les programmes utilisés et gérer les tonnes de dépendances qui en découlent avec les problèmes que cela génèrent parfois (exemple: programme fonctionne bien avec libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl 2.0.2... ou inversement). Les deux approches ont des avantages et des inconvénients. Ma préférence personnelle va Í l'approche "Windows" de par sa simplicité pour l'utilisateur, au détriment d'un peu d'espace disque sacrifié (et un peu de RAM éventuellement). Ce qui me fatiguent le plus, c'est les logiciels "modernes" en python, ruby ou autre abomination, avec des systèmes de dépendances exotiques qui rentrent parfois en conflit avec le gestionnaire de la distribution. J'en arrive parfois Í regretter l'ancien temps - sous DOS, tout était bien plus simple! Matthieu
Le 05.07.2022 Í 17:01 Christophe PEREZ a écrit:
Le 05 Jul 2022 18:37:06 GMT,
william <blop@no.spam> a écrit :
> Alors que pour windows, un simple binaire et il y avait tout
> dedans.
Euh... oui mais non.
Il me semble bien que sous Windows, pour ce dont je me souviens, il y
avait des dll un peu partout
Ce n'était/n'est pas la règle je crois, plutÍ´t des exceptions pour des
trucs plus ou moins "standard" comme MSVCRT, DirectX etc... Et c'est
vrai que ce n'est pas exceptionnellement propre. Il n'en reste que la
vaste majorité des programmes Windows se lancent sans dépendances
extérieures Í WinAPI.
C'est possible sous Linux aussi, via des binaires statiques, mais ce
n'est pas la règle. Au contraire, les Linuxiens préfèrent gérer des
milliers de bibliothèques, y lier dynamiquement les programmes utilisés
et gérer les tonnes de dépendances qui en découlent avec les problèmes
que cela génèrent parfois (exemple: programme fonctionne bien avec
libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl
2.0.2... ou inversement).
Les deux approches ont des avantages et des inconvénients. Ma préférence
personnelle va Í l'approche "Windows" de par sa simplicité pour
l'utilisateur, au détriment d'un peu d'espace disque sacrifié (et un
peu de RAM éventuellement). Ce qui me fatiguent le plus, c'est les
logiciels "modernes" en python, ruby ou autre abomination, avec des
systèmes de dépendances exotiques qui rentrent parfois en conflit avec
le gestionnaire de la distribution. J'en arrive parfois Í regretter
l'ancien temps - sous DOS, tout était bien plus simple!
Alors que pour windows, un simple binaire et il y avait tout dedans.
Euh... oui mais non. Il me semble bien que sous Windows, pour ce dont je me souviens, il y avait des dll un peu partout
Ce n'était/n'est pas la règle je crois, plutÍ´t des exceptions pour des trucs plus ou moins "standard" comme MSVCRT, DirectX etc... Et c'est vrai que ce n'est pas exceptionnellement propre. Il n'en reste que la vaste majorité des programmes Windows se lancent sans dépendances extérieures Í WinAPI. C'est possible sous Linux aussi, via des binaires statiques, mais ce n'est pas la règle. Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques, y lier dynamiquement les programmes utilisés et gérer les tonnes de dépendances qui en découlent avec les problèmes que cela génèrent parfois (exemple: programme fonctionne bien avec libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl 2.0.2... ou inversement). Les deux approches ont des avantages et des inconvénients. Ma préférence personnelle va Í l'approche "Windows" de par sa simplicité pour l'utilisateur, au détriment d'un peu d'espace disque sacrifié (et un peu de RAM éventuellement). Ce qui me fatiguent le plus, c'est les logiciels "modernes" en python, ruby ou autre abomination, avec des systèmes de dépendances exotiques qui rentrent parfois en conflit avec le gestionnaire de la distribution. J'en arrive parfois Í regretter l'ancien temps - sous DOS, tout était bien plus simple! Matthieu
Christophe PEREZ
Le Wed, 6 Jul 2022 09:11:13 +0200, Matthieu a écrit :
Ce n'était/n'est pas la règle je crois, plutÍ´t des exceptions pour des trucs plus ou moins "standard" comme MSVCRT, DirectX etc... Et c'est vrai que ce n'est pas exceptionnellement propre. Il n'en reste que la vaste majorité des programmes Windows se lancent sans dépendances extérieures Í WinAPI.
Il y a 20 ans, c'était très très loin d'être rare, bien au contraire. Depuis, je ne sais pas, je n'ai jamais retouché Í windows.
C'est possible sous Linux aussi, via des binaires statiques,
Beurk !
mais ce n'est pas la règle.
Encore heureux !
Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques,
Non, les linuxiens ne gèrent rien de ça, le système de gestion des dépendances de leur distribution est lÍ pour ça.
y lier dynamiquement les programmes utilisés et gérer les tonnes de dépendances qui en découlent avec les problèmes que cela génèrent parfois (exemple: programme fonctionne bien avec libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl 2.0.2... ou inversement).
Mise Í jour d'une dépendance = mise Í jour de tous les logiciels en dépendant. C'est simple comme concept.
Les deux approches ont des avantages et des inconvénients.
Oui. L'une va dans le sens de la simplicité d'installation, même si ça ne fonctionne pas ensuite et fout en l'air tout le système. Et l'autre n'a comme inconvénient que de faire bosser ceux qui créent les système de gestion des dépendances pour le bien des utilisateurs.
Ma préférence personnelle va Í l'approche "Windows" de par sa simplicité pour l'utilisateur, au détriment d'un peu d'espace disque sacrifié
Non, au détriment d'inefficacité (ne pas utiliser la dernière bibliothèque peut être un risque de sécurité et Í minima ne pas profiter de ses dernières évolutions), de lourdeur (une faille de sécurité d'une partie commune Í tous ces logiciels impose une mise Í jour de chacun d'eux, et sans gestion de dépendance commune, c'est Í la charge de l'utilisateur/installateur, donc finalement bien plus compliqué)
(et un peu de RAM éventuellement). Ce qui me fatiguent le plus, c'est les logiciels "modernes" en python, ruby ou autre abomination, avec des systèmes de dépendances exotiques qui rentrent parfois en conflit avec le gestionnaire de la distribution.
Mauvaise distribution, changer distribution.
J'en arrive parfois Í regretter l'ancien temps - sous DOS, tout était bien plus simple!
A parce que malgré tous les avantages que tu trouves Í windows, tu es quand même sous Linux ? Juste pour la gratuité ? Ou par masochisme ?
Le Wed, 6 Jul 2022 09:11:13 +0200,
Matthieu <matthieu@x.localhost> a écrit :
Ce n'était/n'est pas la règle je crois, plutÍ´t des exceptions pour des
trucs plus ou moins "standard" comme MSVCRT, DirectX etc... Et c'est
vrai que ce n'est pas exceptionnellement propre. Il n'en reste que la
vaste majorité des programmes Windows se lancent sans dépendances
extérieures Í WinAPI.
Il y a 20 ans, c'était très très loin d'être rare, bien au contraire.
Depuis, je ne sais pas, je n'ai jamais retouché Í windows.
C'est possible sous Linux aussi, via des binaires statiques,
Beurk !
mais ce n'est pas la règle.
Encore heureux !
Au contraire, les Linuxiens préfèrent gérer des
milliers de bibliothèques,
Non, les linuxiens ne gèrent rien de ça, le système de gestion des
dépendances de leur distribution est lÍ pour ça.
y lier dynamiquement les programmes
utilisés et gérer les tonnes de dépendances qui en découlent avec les
problèmes que cela génèrent parfois (exemple: programme fonctionne
bien avec libsdl 2.0.1, mais cesse de fonctionner après upgrade vers
libsdl 2.0.2... ou inversement).
Mise Í jour d'une dépendance = mise Í jour de tous les logiciels en
dépendant. C'est simple comme concept.
Les deux approches ont des avantages et des inconvénients.
Oui. L'une va dans le sens de la simplicité d'installation, même si ça
ne fonctionne pas ensuite et fout en l'air tout le système.
Et l'autre n'a comme inconvénient que de faire bosser ceux qui créent
les système de gestion des dépendances pour le bien des utilisateurs.
Ma
préférence personnelle va Í l'approche "Windows" de par sa simplicité
pour l'utilisateur, au détriment d'un peu d'espace disque sacrifié
Non, au détriment d'inefficacité (ne pas utiliser la dernière
bibliothèque peut être un risque de sécurité et Í minima ne pas
profiter de ses dernières évolutions), de lourdeur (une faille de
sécurité d'une partie commune Í tous ces logiciels impose une mise Í
jour de chacun d'eux, et sans gestion de dépendance commune, c'est Í la
charge de l'utilisateur/installateur, donc finalement bien plus
compliqué)
(et un peu de RAM éventuellement). Ce qui me fatiguent le plus, c'est
les logiciels "modernes" en python, ruby ou autre abomination, avec
des systèmes de dépendances exotiques qui rentrent parfois en conflit
avec le gestionnaire de la distribution.
Mauvaise distribution, changer distribution.
J'en arrive parfois Í
regretter l'ancien temps - sous DOS, tout était bien plus simple!
A parce que malgré tous les avantages que tu trouves Í windows, tu es
quand même sous Linux ? Juste pour la gratuité ? Ou par masochisme ?
Le Wed, 6 Jul 2022 09:11:13 +0200, Matthieu a écrit :
Ce n'était/n'est pas la règle je crois, plutÍ´t des exceptions pour des trucs plus ou moins "standard" comme MSVCRT, DirectX etc... Et c'est vrai que ce n'est pas exceptionnellement propre. Il n'en reste que la vaste majorité des programmes Windows se lancent sans dépendances extérieures Í WinAPI.
Il y a 20 ans, c'était très très loin d'être rare, bien au contraire. Depuis, je ne sais pas, je n'ai jamais retouché Í windows.
C'est possible sous Linux aussi, via des binaires statiques,
Beurk !
mais ce n'est pas la règle.
Encore heureux !
Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques,
Non, les linuxiens ne gèrent rien de ça, le système de gestion des dépendances de leur distribution est lÍ pour ça.
y lier dynamiquement les programmes utilisés et gérer les tonnes de dépendances qui en découlent avec les problèmes que cela génèrent parfois (exemple: programme fonctionne bien avec libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl 2.0.2... ou inversement).
Mise Í jour d'une dépendance = mise Í jour de tous les logiciels en dépendant. C'est simple comme concept.
Les deux approches ont des avantages et des inconvénients.
Oui. L'une va dans le sens de la simplicité d'installation, même si ça ne fonctionne pas ensuite et fout en l'air tout le système. Et l'autre n'a comme inconvénient que de faire bosser ceux qui créent les système de gestion des dépendances pour le bien des utilisateurs.
Ma préférence personnelle va Í l'approche "Windows" de par sa simplicité pour l'utilisateur, au détriment d'un peu d'espace disque sacrifié
Non, au détriment d'inefficacité (ne pas utiliser la dernière bibliothèque peut être un risque de sécurité et Í minima ne pas profiter de ses dernières évolutions), de lourdeur (une faille de sécurité d'une partie commune Í tous ces logiciels impose une mise Í jour de chacun d'eux, et sans gestion de dépendance commune, c'est Í la charge de l'utilisateur/installateur, donc finalement bien plus compliqué)
(et un peu de RAM éventuellement). Ce qui me fatiguent le plus, c'est les logiciels "modernes" en python, ruby ou autre abomination, avec des systèmes de dépendances exotiques qui rentrent parfois en conflit avec le gestionnaire de la distribution.
Mauvaise distribution, changer distribution.
J'en arrive parfois Í regretter l'ancien temps - sous DOS, tout était bien plus simple!
A parce que malgré tous les avantages que tu trouves Í windows, tu es quand même sous Linux ? Juste pour la gratuité ? Ou par masochisme ?
Matthieu
Le 06.07.2022 Í 16:44 Christophe PEREZ a écrit:
Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques,
Non, les linuxiens ne gèrent rien de ça, le système de gestion des dépendances de leur distribution est lÍ pour ça.
Il n'y a rien de magique, toutes ces dépendances doivent être gérées par des humains Í un moment ou un autre.
Mise Í jour d'une dépendance = mise Í jour de tous les logiciels en dépendant. C'est simple comme concept.
Encore du travail gratuit. Et non, une mise Í jour mineure d'une bibliothèque n’entraÍ®ne absolument pas la mise Í jour de tous les logiciels qui en dépendent. Ce serait une catastrophe si c'était le cas. Ce concept a ses limites: J'ai déjÍ eu le cas ou des utilisateurs se plaignaient qu'un de mes programmes ne fonctionnaient plus sur la distribution X (qui l'incluait). Après investigation, il s'est avéré qu'une mise Í jour mineure d'une bibliothèque avait introduit un comportement différent d'une des fonctions de cette bibliothèque. Le développeur crée ses programmes sur une version X de bibliothèque, il valide et qualifie leur fonctionnement. Si une bibliothèque change de comportement dans une version X.X+1, il n'y peut pas grand chose. C'est la raison pour laquelle j'ai une préférence pour les binaires statiques - je sais qu'ils contiennent exactement ce que le fournisseur/développeur a testé et validé.
Oui. L'une va dans le sens de la simplicité d'installation, même si ça ne fonctionne pas ensuite et fout en l'air tout le système.
Au contraire, les binaires statiques fonctionnent parfaitement, et n'ont aucun impact sur le reste du système.
Et l'autre n'a comme inconvénient que de faire bosser ceux qui créent les système de gestion des dépendances pour le bien des utilisateurs.
C'est une vision bien idéaliste de la chose.
J'en arrive parfois Í regretter l'ancien temps - sous DOS, tout était bien plus simple!
A parce que malgré tous les avantages que tu trouves Í windows, tu es quand même sous Linux ? Juste pour la gratuité ? Ou par masochisme ?
La distribution de binaires statiques n'est pas un avantage de Windows, c'est juste une méthode de distribution. Que certains éditeurs sérieux commencent d'ailleurs Í utiliser y compris sous Linux (cf. AppImage, entre autres). Matthieu
Le 06.07.2022 Í 16:44 Christophe PEREZ a écrit:
> Au contraire, les Linuxiens préfèrent gérer des
> milliers de bibliothèques,
Non, les linuxiens ne gèrent rien de ça, le système de gestion des
dépendances de leur distribution est lÍ pour ça.
Il n'y a rien de magique, toutes ces dépendances doivent être gérées
par des humains Í un moment ou un autre.
Mise Í jour d'une dépendance = mise Í jour de tous les logiciels en
dépendant. C'est simple comme concept.
Encore du travail gratuit. Et non, une mise Í jour mineure d'une
bibliothèque n’entraÍ®ne absolument pas la mise Í jour de tous les
logiciels qui en dépendent. Ce serait une catastrophe si c'était le
cas.
Ce concept a ses limites: J'ai déjÍ eu le cas ou des utilisateurs se
plaignaient qu'un de mes programmes ne fonctionnaient plus sur la
distribution X (qui l'incluait). Après investigation, il s'est avéré
qu'une mise Í jour mineure d'une bibliothèque avait introduit un
comportement différent d'une des fonctions de cette bibliothèque. Le
développeur crée ses programmes sur une version X de bibliothèque, il
valide et qualifie leur fonctionnement. Si une bibliothèque change de
comportement dans une version X.X+1, il n'y peut pas grand chose. C'est
la raison pour laquelle j'ai une préférence pour les binaires statiques
- je sais qu'ils contiennent exactement ce que le
fournisseur/développeur a testé et validé.
Oui. L'une va dans le sens de la simplicité d'installation, même si ça
ne fonctionne pas ensuite et fout en l'air tout le système.
Au contraire, les binaires statiques fonctionnent parfaitement, et n'ont
aucun impact sur le reste du système.
Et l'autre n'a comme inconvénient que de faire bosser ceux qui créent
les système de gestion des dépendances pour le bien des utilisateurs.
C'est une vision bien idéaliste de la chose.
> J'en arrive parfois Í
> regretter l'ancien temps - sous DOS, tout était bien plus simple!
A parce que malgré tous les avantages que tu trouves Í windows, tu es
quand même sous Linux ? Juste pour la gratuité ? Ou par masochisme ?
La distribution de binaires statiques n'est pas un avantage de Windows,
c'est juste une méthode de distribution. Que certains éditeurs sérieux
commencent d'ailleurs Í utiliser y compris sous Linux (cf. AppImage,
entre autres).
Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques,
Non, les linuxiens ne gèrent rien de ça, le système de gestion des dépendances de leur distribution est lÍ pour ça.
Il n'y a rien de magique, toutes ces dépendances doivent être gérées par des humains Í un moment ou un autre.
Mise Í jour d'une dépendance = mise Í jour de tous les logiciels en dépendant. C'est simple comme concept.
Encore du travail gratuit. Et non, une mise Í jour mineure d'une bibliothèque n’entraÍ®ne absolument pas la mise Í jour de tous les logiciels qui en dépendent. Ce serait une catastrophe si c'était le cas. Ce concept a ses limites: J'ai déjÍ eu le cas ou des utilisateurs se plaignaient qu'un de mes programmes ne fonctionnaient plus sur la distribution X (qui l'incluait). Après investigation, il s'est avéré qu'une mise Í jour mineure d'une bibliothèque avait introduit un comportement différent d'une des fonctions de cette bibliothèque. Le développeur crée ses programmes sur une version X de bibliothèque, il valide et qualifie leur fonctionnement. Si une bibliothèque change de comportement dans une version X.X+1, il n'y peut pas grand chose. C'est la raison pour laquelle j'ai une préférence pour les binaires statiques - je sais qu'ils contiennent exactement ce que le fournisseur/développeur a testé et validé.
Oui. L'une va dans le sens de la simplicité d'installation, même si ça ne fonctionne pas ensuite et fout en l'air tout le système.
Au contraire, les binaires statiques fonctionnent parfaitement, et n'ont aucun impact sur le reste du système.
Et l'autre n'a comme inconvénient que de faire bosser ceux qui créent les système de gestion des dépendances pour le bien des utilisateurs.
C'est une vision bien idéaliste de la chose.
J'en arrive parfois Í regretter l'ancien temps - sous DOS, tout était bien plus simple!
A parce que malgré tous les avantages que tu trouves Í windows, tu es quand même sous Linux ? Juste pour la gratuité ? Ou par masochisme ?
La distribution de binaires statiques n'est pas un avantage de Windows, c'est juste une méthode de distribution. Que certains éditeurs sérieux commencent d'ailleurs Í utiliser y compris sous Linux (cf. AppImage, entre autres). Matthieu
GERBIER Eric
Bonjour Moi, je pense sécurité : imaginons une grosse faille sur la librairie ssl. - en mode statique, cela veut dire qu'il faut recompiler tous les binaires qui l'utilisent, ce qui est long et on risque d'en oublier ... - en mode dynamique, on change la lib, on redemarre les services, et on est protégé
Bonjour
Moi, je pense sécurité : imaginons une grosse faille sur la librairie ssl.
- en mode statique, cela veut dire qu'il faut recompiler tous les binaires qui l'utilisent, ce qui
est long et on risque d'en oublier ...
- en mode dynamique, on change la lib, on redemarre les services, et on est protégé
Bonjour Moi, je pense sécurité : imaginons une grosse faille sur la librairie ssl. - en mode statique, cela veut dire qu'il faut recompiler tous les binaires qui l'utilisent, ce qui est long et on risque d'en oublier ... - en mode dynamique, on change la lib, on redemarre les services, et on est protégé
Matthieu
Le 07.07.2022 Í 09:15 GERBIER Eric a écrit:
Bonjour Moi, je pense sécurité : imaginons une grosse faille sur la librairie ssl. - en mode statique, cela veut dire qu'il faut recompiler tous les binaires qui l'utilisent, ce qui est long et on risque d'en oublier ... - en mode dynamique, on change la lib, on redemarre les services, et on est protégé
Inversement, une faille peut être introduite dans une version postérieure. On met Í jour et pouf, 100% de nos logiciels SSL/TLS devient vulnérable. C'est un cas extrême bien sÍ»r, mais tout n'est pas blanc ou noir. En fonction du besoin, des approches différentes peuvent être envisagées. Je n'ai pas du tout le même regard sur mon service nginx frontal que sur mon éditeur de dessins techniques par exemple. Matthieu
Le 07.07.2022 Í 09:15 GERBIER Eric a écrit:
Bonjour
Moi, je pense sécurité : imaginons une grosse faille sur la librairie
ssl.
- en mode statique, cela veut dire qu'il faut recompiler tous les
binaires qui l'utilisent, ce qui est long et on risque d'en oublier
...
- en mode dynamique, on change la lib, on redemarre les services, et
on est protégé
Inversement, une faille peut être introduite dans une version
postérieure. On met Í jour et pouf, 100% de nos logiciels SSL/TLS
devient vulnérable.
C'est un cas extrême bien sÍ»r, mais tout n'est pas blanc ou noir. En
fonction du besoin, des approches différentes peuvent être envisagées.
Je n'ai pas du tout le même regard sur mon service nginx frontal que
sur mon éditeur de dessins techniques par exemple.
Bonjour Moi, je pense sécurité : imaginons une grosse faille sur la librairie ssl. - en mode statique, cela veut dire qu'il faut recompiler tous les binaires qui l'utilisent, ce qui est long et on risque d'en oublier ... - en mode dynamique, on change la lib, on redemarre les services, et on est protégé
Inversement, une faille peut être introduite dans une version postérieure. On met Í jour et pouf, 100% de nos logiciels SSL/TLS devient vulnérable. C'est un cas extrême bien sÍ»r, mais tout n'est pas blanc ou noir. En fonction du besoin, des approches différentes peuvent être envisagées. Je n'ai pas du tout le même regard sur mon service nginx frontal que sur mon éditeur de dessins techniques par exemple. Matthieu
Nicolas George
Matthieu , dans le message <ta61fe$mqv$, a écrit :
Inversement, une faille peut être introduite dans une version postérieure.
Et corrigée dans la version d'après, donc cet argument n'apporte rien Í la discussion.
Matthieu , dans le message <ta61fe$mqv$2@gioia.aioe.org>, a écrit :
Inversement, une faille peut être introduite dans une version
postérieure.
Et corrigée dans la version d'après, donc cet argument n'apporte rien Í la
discussion.
Matthieu , dans le message <ta61fe$mqv$, a écrit :
Inversement, une faille peut être introduite dans une version postérieure.
Et corrigée dans la version d'après, donc cet argument n'apporte rien Í la discussion.
Nicolas George
Matthieu , dans le message <ta60f6$mqv$, a écrit :
Il n'y a rien de magique, toutes ces dépendances doivent être gérées par des humains Í un moment ou un autre.
En effet. Et c'est vrai également dans le cas o͹ la dépendance est fournie avec le logiciel. La seule différence, c'est que dans un cas les dépendances sont gérées par les mainteneurs de la distribution, des gens qui ont l'habitude de gérer efficacement les dépendances et qui disposent d'outils puissants pour automatiser leur travail, alors que dans l'autre cas les dépendances sont gérées par les développeurs de l'application, qui n'ont aucune compétence particulière dans la gestion des dépendances. Les implication de cette situation pour la sécurité, en particulier, viennent de t'être expliquées.
Ce concept a ses limites: J'ai déjÍ eu le cas ou des utilisateurs se plaignaient qu'un de mes programmes ne fonctionnaient plus sur la distribution X (qui l'incluait). Après investigation, il s'est avéré qu'une mise Í jour mineure d'une bibliothèque avait introduit un comportement différent d'une des fonctions de cette bibliothèque. Le développeur crée ses programmes sur une version X de bibliothèque, il valide et qualifie leur fonctionnement. Si une bibliothèque change de comportement dans une version X.X+1, il n'y peut pas grand chose. C'est la raison pour laquelle j'ai une préférence pour les binaires statiques - je sais qu'ils contiennent exactement ce que le fournisseur/développeur a testé et validé.
Un développeur compétent teste son logiciel sur plusieurs versions des bibliothèques, ou demande Í ses utilisateurs de le faire s'il n'a pas le temps tout seul. Un développeur compétent sait, les quelles des bibliothèques qu'il utilise tiennent leurs promesses de stabilité d'API ou pas. Les binaires statiques et les packages lourds, c'est aussi la grande joie des développeurs médiocres qui ne savent pas programmer de manière portable, lire la doc d'une bibliothèque pour utiliser ses fonctionnalités comme documenté plutÍ´t que d'exploiter des coͯncidences, et qui vont se précipiter vers des bibliothèques médiocres et mal ficelées parce qu'ils ne sont pas capables d'implémenter eux-mêmes des fonctionnalités élémentaires.
Matthieu , dans le message <ta60f6$mqv$1@gioia.aioe.org>, a écrit :
Il n'y a rien de magique, toutes ces dépendances doivent être gérées
par des humains Í un moment ou un autre.
En effet. Et c'est vrai également dans le cas o͹ la dépendance est fournie
avec le logiciel. La seule différence, c'est que dans un cas les dépendances
sont gérées par les mainteneurs de la distribution, des gens qui ont
l'habitude de gérer efficacement les dépendances et qui disposent d'outils
puissants pour automatiser leur travail, alors que dans l'autre cas les
dépendances sont gérées par les développeurs de l'application, qui n'ont
aucune compétence particulière dans la gestion des dépendances.
Les implication de cette situation pour la sécurité, en particulier,
viennent de t'être expliquées.
Ce concept a ses limites: J'ai déjÍ eu le cas ou des utilisateurs se
plaignaient qu'un de mes programmes ne fonctionnaient plus sur la
distribution X (qui l'incluait). Après investigation, il s'est avéré
qu'une mise Í jour mineure d'une bibliothèque avait introduit un
comportement différent d'une des fonctions de cette bibliothèque. Le
développeur crée ses programmes sur une version X de bibliothèque, il
valide et qualifie leur fonctionnement. Si une bibliothèque change de
comportement dans une version X.X+1, il n'y peut pas grand chose. C'est
la raison pour laquelle j'ai une préférence pour les binaires statiques
- je sais qu'ils contiennent exactement ce que le
fournisseur/développeur a testé et validé.
Un développeur compétent teste son logiciel sur plusieurs versions des
bibliothèques, ou demande Í ses utilisateurs de le faire s'il n'a pas le
temps tout seul.
Un développeur compétent sait, les quelles des bibliothèques qu'il utilise
tiennent leurs promesses de stabilité d'API ou pas.
Les binaires statiques et les packages lourds, c'est aussi la grande joie
des développeurs médiocres qui ne savent pas programmer de manière portable,
lire la doc d'une bibliothèque pour utiliser ses fonctionnalités comme
documenté plutÍ´t que d'exploiter des coͯncidences, et qui vont se précipiter
vers des bibliothèques médiocres et mal ficelées parce qu'ils ne sont pas
capables d'implémenter eux-mêmes des fonctionnalités élémentaires.
Matthieu , dans le message <ta60f6$mqv$, a écrit :
Il n'y a rien de magique, toutes ces dépendances doivent être gérées par des humains Í un moment ou un autre.
En effet. Et c'est vrai également dans le cas o͹ la dépendance est fournie avec le logiciel. La seule différence, c'est que dans un cas les dépendances sont gérées par les mainteneurs de la distribution, des gens qui ont l'habitude de gérer efficacement les dépendances et qui disposent d'outils puissants pour automatiser leur travail, alors que dans l'autre cas les dépendances sont gérées par les développeurs de l'application, qui n'ont aucune compétence particulière dans la gestion des dépendances. Les implication de cette situation pour la sécurité, en particulier, viennent de t'être expliquées.
Ce concept a ses limites: J'ai déjÍ eu le cas ou des utilisateurs se plaignaient qu'un de mes programmes ne fonctionnaient plus sur la distribution X (qui l'incluait). Après investigation, il s'est avéré qu'une mise Í jour mineure d'une bibliothèque avait introduit un comportement différent d'une des fonctions de cette bibliothèque. Le développeur crée ses programmes sur une version X de bibliothèque, il valide et qualifie leur fonctionnement. Si une bibliothèque change de comportement dans une version X.X+1, il n'y peut pas grand chose. C'est la raison pour laquelle j'ai une préférence pour les binaires statiques - je sais qu'ils contiennent exactement ce que le fournisseur/développeur a testé et validé.
Un développeur compétent teste son logiciel sur plusieurs versions des bibliothèques, ou demande Í ses utilisateurs de le faire s'il n'a pas le temps tout seul. Un développeur compétent sait, les quelles des bibliothèques qu'il utilise tiennent leurs promesses de stabilité d'API ou pas. Les binaires statiques et les packages lourds, c'est aussi la grande joie des développeurs médiocres qui ne savent pas programmer de manière portable, lire la doc d'une bibliothèque pour utiliser ses fonctionnalités comme documenté plutÍ´t que d'exploiter des coͯncidences, et qui vont se précipiter vers des bibliothèques médiocres et mal ficelées parce qu'ils ne sont pas capables d'implémenter eux-mêmes des fonctionnalités élémentaires.
