J'aimerais avoir votre avis sur la gestion des dépendances de MacOS
comparée à celle de linux.
Sous Mac (en applications natives), il n'y a pas de dépendances, toutes
les librairies nécessaires à l'appli sont dans le folder .app de
l'application.
Sous linux, il y a une gestion complexe des dépendances.
Donc sur Mac pour installer une appli on la copie sur son disque dur et
on lui donne les autorisations d'exécution (la demande de mot de passe à
l'install dans le dossier /Applications).
Sous Linux vous savez comment cela fonctionne.
Un exemple ou cela serait utile :
- Ubuntu server 9.10
- python 2.6 (version installée par défaut)
- apt-get fail2ban
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.
Donc il faut faire en plus
- apt-get install python2.5
- modifier les fichiers de fail2ban pour utiliser cette version
Ce ne serait pas arrivé sur Mac.
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
En effet c'est possible. Mais je préfère utiliser la librairie qu e le dev à utiliser que de toujours avoir la dernière. En effet, un so ft peu très bien ne plus fonctionner avec la dernière version de la lib.
Une correction de sécurité ne fait que corriger la faille. Il doit continuer à fonctionner avec la lib corrigée. Ou alors, c'est autre chose que tu as installé.
JEf a écrit:
En effet c'est possible. Mais je préfère utiliser la librairie qu e le
dev à utiliser que de toujours avoir la dernière. En effet, un so ft peu
très bien ne plus fonctionner avec la dernière version de la lib.
Une correction de sécurité ne fait que corriger la faille. Il doit continuer
à fonctionner avec la lib corrigée. Ou alors, c'est autre chose que tu as
installé.
En effet c'est possible. Mais je préfère utiliser la librairie qu e le dev à utiliser que de toujours avoir la dernière. En effet, un so ft peu très bien ne plus fonctionner avec la dernière version de la lib.
Une correction de sécurité ne fait que corriger la faille. Il doit continuer à fonctionner avec la lib corrigée. Ou alors, c'est autre chose que tu as installé.
JEf
On 10/08/10 21:44, Tonton Th wrote:
On 08/10/2010 01:39 PM, JEf wrote:
Pas dans le cas d'espèce mais quand bien même je ne vais pas laisser mon serveur crasher parce que ce soft n'est pas une priorité chez debian.
Si ce soft a une priorité plus forte chez toi que chez Debian, c'est à toi de gérer manuellement la chose. Il est donc temps de passer au papier, au crayon, à la gomme et à Slackware.
Pourquoi ?
Donc parce que Debian n'a pas été rapide sur la balle, j'aurais du passer mon temps à changer la distrib (qui me convient d'ailleurs pour tout le reste) sur 60 serveurs ? Avec le temps d'indispo sur chaque serveur et mon temps à moi, ça couterait cher pour éviter de faire un dpkg -i d'un .deb quand même, non ?
Ma version .deb s'installe dans un autre endroit, donc la version qui vient avec debian ne gène pas. Quand elle sera de version équivalente, je repasserai dessus et supprimerai celle dans /usr/local/bin.
Si je te suis bien, selon toi, aucun dev ne devrait utiliser debian parce qu'il lui faut par définition utiliser des choses qui ne sont pas dans le gestionnaire de paquets ?
JEf
On 10/08/10 21:44, Tonton Th wrote:
On 08/10/2010 01:39 PM, JEf wrote:
Pas dans le cas d'espèce mais quand bien même je ne vais pas laisser mon
serveur crasher parce que ce soft n'est pas une priorité chez debian.
Si ce soft a une priorité plus forte chez toi que chez Debian,
c'est à toi de gérer manuellement la chose. Il est donc temps
de passer au papier, au crayon, à la gomme et à Slackware.
Pourquoi ?
Donc parce que Debian n'a pas été rapide sur la balle, j'aurais du
passer mon temps à changer la distrib (qui me convient d'ailleurs pour
tout le reste) sur 60 serveurs ? Avec le temps d'indispo sur chaque
serveur et mon temps à moi, ça couterait cher pour éviter de faire un
dpkg -i d'un .deb quand même, non ?
Ma version .deb s'installe dans un autre endroit, donc la version qui
vient avec debian ne gène pas. Quand elle sera de version équivalente,
je repasserai dessus et supprimerai celle dans /usr/local/bin.
Si je te suis bien, selon toi, aucun dev ne devrait utiliser debian
parce qu'il lui faut par définition utiliser des choses qui ne sont pas
dans le gestionnaire de paquets ?
Pas dans le cas d'espèce mais quand bien même je ne vais pas laisser mon serveur crasher parce que ce soft n'est pas une priorité chez debian.
Si ce soft a une priorité plus forte chez toi que chez Debian, c'est à toi de gérer manuellement la chose. Il est donc temps de passer au papier, au crayon, à la gomme et à Slackware.
Pourquoi ?
Donc parce que Debian n'a pas été rapide sur la balle, j'aurais du passer mon temps à changer la distrib (qui me convient d'ailleurs pour tout le reste) sur 60 serveurs ? Avec le temps d'indispo sur chaque serveur et mon temps à moi, ça couterait cher pour éviter de faire un dpkg -i d'un .deb quand même, non ?
Ma version .deb s'installe dans un autre endroit, donc la version qui vient avec debian ne gène pas. Quand elle sera de version équivalente, je repasserai dessus et supprimerai celle dans /usr/local/bin.
Si je te suis bien, selon toi, aucun dev ne devrait utiliser debian parce qu'il lui faut par définition utiliser des choses qui ne sont pas dans le gestionnaire de paquets ?
JEf
JEf
On 10/08/10 22:08, Stephane CARPENTIER wrote:
JEf a écrit:
En effet c'est possible. Mais je préfère utiliser la librairie que le dev à utiliser que de toujours avoir la dernière. En effet, un soft peu très bien ne plus fonctionner avec la dernière version de la lib.
Une correction de sécurité ne fait que corriger la faille. Il doit continuer à fonctionner avec la lib corrigée. Ou alors, c'est autre chose que tu as installé.
Oui c'est pour ça que je distinguais : - si mise à jour de sécurité uniquement, ça ne pose généralement pas de prob - si ajout de fonctions, ça peut poser des probs d'upgrader
HTH
JEf
On 10/08/10 22:08, Stephane CARPENTIER wrote:
JEf a écrit:
En effet c'est possible. Mais je préfère utiliser la librairie que le
dev à utiliser que de toujours avoir la dernière. En effet, un soft peu
très bien ne plus fonctionner avec la dernière version de la lib.
Une correction de sécurité ne fait que corriger la faille. Il doit continuer
à fonctionner avec la lib corrigée. Ou alors, c'est autre chose que tu as
installé.
Oui c'est pour ça que je distinguais :
- si mise à jour de sécurité uniquement, ça ne pose généralement pas de prob
- si ajout de fonctions, ça peut poser des probs d'upgrader
En effet c'est possible. Mais je préfère utiliser la librairie que le dev à utiliser que de toujours avoir la dernière. En effet, un soft peu très bien ne plus fonctionner avec la dernière version de la lib.
Une correction de sécurité ne fait que corriger la faille. Il doit continuer à fonctionner avec la lib corrigée. Ou alors, c'est autre chose que tu as installé.
Oui c'est pour ça que je distinguais : - si mise à jour de sécurité uniquement, ça ne pose généralement pas de prob - si ajout de fonctions, ça peut poser des probs d'upgrader
HTH
JEf
nshag
On 8 août, 10:55, JEf wrote:
Bonjour,
J'aimerais avoir votre avis sur la gestion des dépendances de MacOS comparée à celle de linux.
[snip]
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et p lus de ram. Mais au prix de la ram et des disques, est-ce vraiment un probl ème ?
Ton exemple montre un problème de gestion des dépendances au niveau d'un seul et unique package qui aurait du exiger une version ad-hoc d'une de ses dépendances, en d'autres termes, le mainteneur n'a pas fait son boulot.
Je ne doute pas que tu puisses trouver une foule d'autres exemples du meme genre, mais pour une distribution linux, le problème se pose plus en terme de maintenance et de mises a jours du systeme dans son ensemble que de facilité de déploiement ponctuel d'une application. Les consequences de l'approche mac en terme d'obsolescence de packages binaires par exemple sont sans communes mesures avec le petit confort apporté a un mauvais mainteneur qui évitera par se moyen de se sortir les doigts du cul :)
Et pour ce qui est du confort de l'utilisateur, c'est a peu prêt la même chose, un package mal maintenu est susceptible de poser une foule de problemes, et pas que de dépendances a l'installation.
Il semble donc plus intéressant d'opérer une "sélection naturelle" des mainteneurs/packages que de voir se multiplier les versions binaires plus ou moins maintenues et par la même occasion les problèmes que l'utilisateur risque de rencontrer autant de fois que de versions binaires installées :)
On 8 août, 10:55, JEf <mor...@skynet.be> wrote:
Bonjour,
J'aimerais avoir votre avis sur la gestion des dépendances de MacOS
comparée à celle de linux.
[snip]
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et p lus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un probl ème ?
Ton exemple montre un problème de gestion des dépendances au niveau
d'un
seul et unique package qui aurait du exiger une version ad-hoc d'une
de ses
dépendances, en d'autres termes, le mainteneur n'a pas fait son
boulot.
Je ne doute pas que tu puisses trouver une foule d'autres exemples du
meme genre,
mais pour une distribution linux, le problème se pose plus en terme de
maintenance
et de mises a jours du systeme dans son ensemble que de facilité de
déploiement
ponctuel d'une application. Les consequences de l'approche mac en
terme
d'obsolescence de packages binaires par exemple sont sans communes
mesures
avec le petit confort apporté a un mauvais mainteneur qui évitera par
se moyen de
se sortir les doigts du cul :)
Et pour ce qui est du confort de l'utilisateur, c'est a peu prêt la
même chose,
un package mal maintenu est susceptible de poser une foule de
problemes,
et pas que de dépendances a l'installation.
Il semble donc plus intéressant d'opérer une "sélection naturelle"
des mainteneurs/packages que de voir se multiplier les versions
binaires
plus ou moins maintenues et par la même occasion les problèmes que
l'utilisateur risque de rencontrer autant de fois que de versions
binaires
installées :)
J'aimerais avoir votre avis sur la gestion des dépendances de MacOS comparée à celle de linux.
[snip]
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et p lus de ram. Mais au prix de la ram et des disques, est-ce vraiment un probl ème ?
Ton exemple montre un problème de gestion des dépendances au niveau d'un seul et unique package qui aurait du exiger une version ad-hoc d'une de ses dépendances, en d'autres termes, le mainteneur n'a pas fait son boulot.
Je ne doute pas que tu puisses trouver une foule d'autres exemples du meme genre, mais pour une distribution linux, le problème se pose plus en terme de maintenance et de mises a jours du systeme dans son ensemble que de facilité de déploiement ponctuel d'une application. Les consequences de l'approche mac en terme d'obsolescence de packages binaires par exemple sont sans communes mesures avec le petit confort apporté a un mauvais mainteneur qui évitera par se moyen de se sortir les doigts du cul :)
Et pour ce qui est du confort de l'utilisateur, c'est a peu prêt la même chose, un package mal maintenu est susceptible de poser une foule de problemes, et pas que de dépendances a l'installation.
Il semble donc plus intéressant d'opérer une "sélection naturelle" des mainteneurs/packages que de voir se multiplier les versions binaires plus ou moins maintenues et par la même occasion les problèmes que l'utilisateur risque de rencontrer autant de fois que de versions binaires installées :)
JEf
Ah on revient enfin au fond de mon message :-)
On 11/08/10 16:32, nshag wrote:
On 8 août, 10:55, JEf wrote:
Bonjour,
J'aimerais avoir votre avis sur la gestion des dépendances de MacOS comparée à celle de linux.
[snip]
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
Ton exemple montre un problème de gestion des dépendances au niveau d'un seul et unique package qui aurait du exiger une version ad-hoc d'une de ses dépendances, en d'autres termes, le mainteneur n'a pas fait son boulot.
Oui, on est d'accord. Toutefois pour le enduser, que le prob se situe au niveau du dev ou du mainteneur du paquet, le problème est le même. Ca ne fonctionne pas.
Je ne doute pas que tu puisses trouver une foule d'autres exemples du meme genre,
Je n'en doute pas non plus :-)
Mon point est que d'un point de vue enduser, il est plus simple de faire du drag'n drop des applis et que ça fonctionne directement que de chercher l'obscure cause d'un disfonctionnement de son application.
Dans le cadre du desktop et de l'utilisateur michu le ressenti sera plus positif avec un fonctionnement à la mac.
En gros sur mac j'installe l'application brol1.app et ça fonctionne pas bien => poubelle. Mais brol1 ne peut en aucun cas perturbé brol2 alors c'est pas trop grave.
Sur linux j'installe l'application brol1 aussi et ça fonctionne mais la semaine suivante je lance l'application brol2 qui elle ne fonctionne pas mais en fait brol2 ne fonctionne plus à cause de brol1 (paquet pourri). Et bien l'utilisateur Michu il va dire, tout pourri brol2, à la poubelle. L'utilisateur avancé, lui, va aller voir les logs, va voir que brol1 a mis le souk et va réparer son brol2 et sans doute virer brol1.
JEf
Ah on revient enfin au fond de mon message :-)
On 11/08/10 16:32, nshag wrote:
On 8 août, 10:55, JEf<mor...@skynet.be> wrote:
Bonjour,
J'aimerais avoir votre avis sur la gestion des dépendances de MacOS
comparée à celle de linux.
[snip]
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
Ton exemple montre un problème de gestion des dépendances au niveau
d'un
seul et unique package qui aurait du exiger une version ad-hoc d'une
de ses
dépendances, en d'autres termes, le mainteneur n'a pas fait son
boulot.
Oui, on est d'accord. Toutefois pour le enduser, que le prob se situe au
niveau du dev ou du mainteneur du paquet, le problème est le même. Ca ne
fonctionne pas.
Je ne doute pas que tu puisses trouver une foule d'autres exemples du
meme genre,
Je n'en doute pas non plus :-)
Mon point est que d'un point de vue enduser, il est plus simple de faire
du drag'n drop des applis et que ça fonctionne directement que de
chercher l'obscure cause d'un disfonctionnement de son application.
Dans le cadre du desktop et de l'utilisateur michu le ressenti sera plus
positif avec un fonctionnement à la mac.
En gros sur mac j'installe l'application brol1.app et ça fonctionne pas
bien => poubelle. Mais brol1 ne peut en aucun cas perturbé brol2 alors
c'est pas trop grave.
Sur linux j'installe l'application brol1 aussi et ça fonctionne mais la
semaine suivante je lance l'application brol2 qui elle ne fonctionne pas
mais en fait brol2 ne fonctionne plus à cause de brol1 (paquet pourri).
Et bien l'utilisateur Michu il va dire, tout pourri brol2, à la
poubelle. L'utilisateur avancé, lui, va aller voir les logs, va voir que
brol1 a mis le souk et va réparer son brol2 et sans doute virer brol1.
J'aimerais avoir votre avis sur la gestion des dépendances de MacOS comparée à celle de linux.
[snip]
Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?
Ton exemple montre un problème de gestion des dépendances au niveau d'un seul et unique package qui aurait du exiger une version ad-hoc d'une de ses dépendances, en d'autres termes, le mainteneur n'a pas fait son boulot.
Oui, on est d'accord. Toutefois pour le enduser, que le prob se situe au niveau du dev ou du mainteneur du paquet, le problème est le même. Ca ne fonctionne pas.
Je ne doute pas que tu puisses trouver une foule d'autres exemples du meme genre,
Je n'en doute pas non plus :-)
Mon point est que d'un point de vue enduser, il est plus simple de faire du drag'n drop des applis et que ça fonctionne directement que de chercher l'obscure cause d'un disfonctionnement de son application.
Dans le cadre du desktop et de l'utilisateur michu le ressenti sera plus positif avec un fonctionnement à la mac.
En gros sur mac j'installe l'application brol1.app et ça fonctionne pas bien => poubelle. Mais brol1 ne peut en aucun cas perturbé brol2 alors c'est pas trop grave.
Sur linux j'installe l'application brol1 aussi et ça fonctionne mais la semaine suivante je lance l'application brol2 qui elle ne fonctionne pas mais en fait brol2 ne fonctionne plus à cause de brol1 (paquet pourri). Et bien l'utilisateur Michu il va dire, tout pourri brol2, à la poubelle. L'utilisateur avancé, lui, va aller voir les logs, va voir que brol1 a mis le souk et va réparer son brol2 et sans doute virer brol1.
JEf
nshag
On 11 août, 16:42, JEf wrote:
Mon point est que d'un point de vue enduser, il est plus simple de faire du drag'n drop des applis et que ça fonctionne directement que de chercher l'obscure cause d'un disfonctionnement de son application.
il est donc souhaitable pour le end user que les dysfonctionnements entrainés par des dependances soient corrigés le plus vite possible, hors plus l'appli integrera directement les dependances plus ses dysfonctionnement seront persistants, maintenance et propagation des corrections en amont oblige :)
Dans le cadre du desktop et de l'utilisateur michu le ressenti sera plus positif avec un fonctionnement à la mac.
il est sur que concilier le ressenti, la stabilité et l'evolution n'est pas un probleme des plus simples, mais surtout l'aspect coopératif de l'évolution du système mac est pour le moins mineur... pour les distribs linux le problème se pose différemment :)
ceci dis je suis presque certain qu'il y a eu quelques distributions ayant adopté l'approche mac, mais je crains que la pluspart aient disparus du fait qu'elles faisaient passer la fréquence des releases stable de debian pour extremement rapide (sans meme parler de la vitesse d'intégration des jouets a la mode :), ce qui insupporte la mère michu au plus haut point :)
et on ne parlera pas non plus des autres guerres de religions, comme les packages dont la relocation (tel que tout foutre dans un dossier dépendances comprises) s'avère être on ne peut plus casse burne :)
de toute façon, "Linux c'est pas pret pour le desktop" (c), thanx godness ;)
On 11 août, 16:42, JEf <mor...@skynet.be> wrote:
Mon point est que d'un point de vue enduser, il est plus simple de faire
du drag'n drop des applis et que ça fonctionne directement que de
chercher l'obscure cause d'un disfonctionnement de son application.
il est donc souhaitable pour le end user que les dysfonctionnements
entrainés par des dependances soient corrigés le plus vite possible,
hors plus l'appli integrera directement les dependances plus ses
dysfonctionnement seront persistants, maintenance et propagation
des corrections en amont oblige :)
Dans le cadre du desktop et de l'utilisateur michu le ressenti sera plus
positif avec un fonctionnement à la mac.
il est sur que concilier le ressenti, la stabilité et l'evolution
n'est pas un
probleme des plus simples, mais surtout l'aspect coopératif de
l'évolution
du système mac est pour le moins mineur... pour les distribs linux
le problème se pose différemment :)
ceci dis je suis presque certain qu'il y a eu quelques distributions
ayant adopté l'approche mac, mais je crains que la pluspart aient
disparus du fait qu'elles faisaient passer la fréquence des releases
stable de debian pour extremement rapide (sans meme parler de
la vitesse d'intégration des jouets a la mode :), ce qui insupporte
la mère michu au plus haut point :)
et on ne parlera pas non plus des autres guerres de religions, comme
les packages dont la relocation (tel que tout foutre dans un dossier
dépendances comprises) s'avère être on ne peut plus casse burne :)
de toute façon, "Linux c'est pas pret pour le desktop" (c), thanx
godness ;)
Mon point est que d'un point de vue enduser, il est plus simple de faire du drag'n drop des applis et que ça fonctionne directement que de chercher l'obscure cause d'un disfonctionnement de son application.
il est donc souhaitable pour le end user que les dysfonctionnements entrainés par des dependances soient corrigés le plus vite possible, hors plus l'appli integrera directement les dependances plus ses dysfonctionnement seront persistants, maintenance et propagation des corrections en amont oblige :)
Dans le cadre du desktop et de l'utilisateur michu le ressenti sera plus positif avec un fonctionnement à la mac.
il est sur que concilier le ressenti, la stabilité et l'evolution n'est pas un probleme des plus simples, mais surtout l'aspect coopératif de l'évolution du système mac est pour le moins mineur... pour les distribs linux le problème se pose différemment :)
ceci dis je suis presque certain qu'il y a eu quelques distributions ayant adopté l'approche mac, mais je crains que la pluspart aient disparus du fait qu'elles faisaient passer la fréquence des releases stable de debian pour extremement rapide (sans meme parler de la vitesse d'intégration des jouets a la mode :), ce qui insupporte la mère michu au plus haut point :)
et on ne parlera pas non plus des autres guerres de religions, comme les packages dont la relocation (tel que tout foutre dans un dossier dépendances comprises) s'avère être on ne peut plus casse burne :)
de toute façon, "Linux c'est pas pret pour le desktop" (c), thanx godness ;)
totof01
On 10 août, 12:30, Nicolas George <nicolas$ wrote:
Je prends un exemple simple : une bibliothèque pour un protocole ré seau, et quatre ou cinq applications d'origines diverses qui l'utilisent. Un bug d e sécurité est découvert dans la bibliothèques ; les développeu rs de la bibliothèque publient immédiatement une version corrigée, totalemen t compatible avec l'ancienne.
Ca c'est le monde idéal ... En pratique tu te retrouves avec des upgrades de libs qui ne préservent pas la compatibilité, et pour une pauvre mise à jour, tu a s 5 ou 6 softs qui tombent.
On 10 août, 12:30, Nicolas George <nicolas$geo...@salle-s.org> wrote:
Je prends un exemple simple : une bibliothèque pour un protocole ré seau, et
quatre ou cinq applications d'origines diverses qui l'utilisent. Un bug d e
sécurité est découvert dans la bibliothèques ; les développeu rs de la
bibliothèque publient immédiatement une version corrigée, totalemen t
compatible avec l'ancienne.
Ca c'est le monde idéal ...
En pratique tu te retrouves avec des upgrades de libs qui ne
préservent pas la compatibilité, et pour une pauvre mise à jour, tu a s
5 ou 6 softs qui tombent.
On 10 août, 12:30, Nicolas George <nicolas$ wrote:
Je prends un exemple simple : une bibliothèque pour un protocole ré seau, et quatre ou cinq applications d'origines diverses qui l'utilisent. Un bug d e sécurité est découvert dans la bibliothèques ; les développeu rs de la bibliothèque publient immédiatement une version corrigée, totalemen t compatible avec l'ancienne.
Ca c'est le monde idéal ... En pratique tu te retrouves avec des upgrades de libs qui ne préservent pas la compatibilité, et pour une pauvre mise à jour, tu a s 5 ou 6 softs qui tombent.
Nicolas George
totof01 , dans le message , a écrit :
Ca c'est le monde idéal ... En pratique tu te retrouves avec des upgrades de libs qui ne préservent pas la compatibilité, et pour une pauvre mise à jour, tu as 5 ou 6 softs qui tombent.
Pas pour un correctif de sécurité, non.
totof01 , dans le message
<150fcbd1-6744-4b75-ab5a-edd98348ccb5@q16g2000prf.googlegroups.com>, a
écrit :
Ca c'est le monde idéal ...
En pratique tu te retrouves avec des upgrades de libs qui ne
préservent pas la compatibilité, et pour une pauvre mise à jour, tu as
5 ou 6 softs qui tombent.
Ca c'est le monde idéal ... En pratique tu te retrouves avec des upgrades de libs qui ne préservent pas la compatibilité, et pour une pauvre mise à jour, tu as 5 ou 6 softs qui tombent.
