[F] iPad (Informatique et high-tech) - Page 252

Brunni (./7529) :
Je sais même pas pourquoi je prends la peine de développer mon point de vue pour avoir pour toute clôture de discussion une réponse équivalente à "de toute façon t'es con" (autrement dit, je n'ai pas cité une seule fois Apple concernant ce sujet ; c'est comme si on discutais et quand j'arrive à court d'argument je te sors "oh et puis ta sœur elle est moche donc t'as tort").

Le problème est que tes arguments ont déjà été cités ici une dizaine de fois et que ça ne les rend pas plus vrais: Par exemple, le problème de simplicité d'installation est un faux problème quand apt/yum/… te télécharge automatiquement toutes les dépendances sans que tu aies à t'en soucier. Et pour le reste:

Brunni (./7525) :
je suis convaincu que quand on utilise un ordinateur on ne veut pas qu'une opération localisée sur une application affecte les autres

Justement, ce n'est pas le cas dans une distribution bien fichue: Soit le programme que tu rajoutes marche avec la version de chaque bibliothèque déjà dans la distribution, soit une nouvelle version de la bibliothèque est sortie en mise à jour pour tout le monde, qu'ils aient installé le nouveau logiciel ou non. Au maximum, l'installation du nouveau logiciel peut te mettre à jour la bibliothèque si ton système n'est pas à jour, mais dans ce cas c'est ça ton problème.

(autre exemple : quand tu désinstallais une appli sous win98, l'uninstaller pouvait effacer des DLL utilisées par d'autres applis)

Ça, c'est un bogue du désinstalleur. Ça n'arrive pas avec un système de dépendances fait correctement. RPM te donne une erreur si tu essaies de désinstaller un paquetage dont d'autres dépendent encore (sans hacks comme --nodeps).

vince (./7530) :
Et concernant le ./7528, en plus du fait que c'est pas ici le sujet, le fait qu'ils justifient pourquoi c'est mieux dans un système de repo de n'utiliser que le principe du système de repo ne représente pas une réponse à la problématique citée plus haut...

Bah non, ils donnent plusieurs raisons pour lesquelles c'est une très mauvaise idée de bundler des bibliothèques, quel que soit le système. (Il en manque une autre, déjà citée par Folco dans le ./7514 et le ./7524: la place prise par les copies inutiles! Et il y a aussi le fait que bundler des bibliothèques dynamiques enlève tout l'intérêt d'utiliser le linkage dynamique, c'est une approche complètement dépourvue de sens.) Donc forcément, un système qui oblige à faire ça est totalement foireux.

Et enfin:

very (./7526) :
Apple c'est de la merde, point barre.

+1

Kevin Kofler (./7531) :
Donc forcément, un système qui oblige à faire ça est totalement foireux.

Justement, c'est là que tu comprends pas : il n'est pas question d'obliger, il est question de laisser le choix, mais c'est vrai que c'est un concept qui t'es peu familier de ce qu'on a pu voir depuis des années... Trois choix devraient être possible, utiliser une biblio bundlée, utiliser une biblio dans la version N et enfin utiliser une biblio dans sa version à jour. Avec un système de repo et de dépendances repensé, ça résoudrait bien des problèmes.

Justement, le système de dépôts laisse le choix (même s'il y en a clairement un qui est plus correct que les autres, mais les raisons sont valables partout!), alors que si on n'a pas de résolution de dépendances, on n'a pas le choix (la méthode Apple: "tu bundles ou tu te casses").

Kevin Kofler (./7531) :
Le problème est que tes arguments ont déjà été cités ici une dizaine de fois et que ça ne les rend pas plus vrais: Par exemple, le problème de simplicité d'installation est un faux problème quand apt/yum/… te télécharge automatiquement toutes les dépendances sans que tu aies à t'en soucier. Et pour le reste:

Mouais, mouais... Tu passes volontairement sous silence les inconvénients du système : il faut être connecté à internet, être root, que la version voulue soit disponible, et qu'elle soit compatible avec tous les logiciels installés... Mais bon, on a l'habitude avec toi.

apt et yum ne permettent pas d'affecter une version particulière d'une lib partagée à une appli.

flanker (./7534) :
et qu'elle soit compatible avec tous les logiciels installés

C'est la distribution qui est en charge de ça.

(C'est pour ça que je préfère les distributions mainstream, plutôt que la foultitude d'autres éclosant sur DistroWatch tous les jours, "basées sur XYZ", mais ne packageant que 10% des softs fournis à la base, et obligeant à crawler dans des repos qui ne vont jamais coller ensemble)

squalyl (./7535) :
apt et yum ne permettent pas d'affecter une version particulière d'une lib partagée à une appli.

Non, ils sont là pour mettre à jour des paquets locaux par rapport à un dépôt. Pas pour dire au système ce qu'il doit utiliser où et quand.

Kevin> Ton raisonnement est trop ancré dans celui d'un Fedora/Linux. Les justifications je les connais déjà et je trouve qu'elles ne justifient pas les désavantages qu'elles causent, désolé.

vince (./7532) :

Kevin Kofler (./7531) :
Donc forcément, un système qui oblige à faire ça est totalement foireux.

Justement, c'est là que tu comprends pas : il n'est pas question d'obliger, il est question de laisser le choix, mais c'est vrai que c'est un concept qui t'es peu familier de ce qu'on a pu voir depuis des années... Trois choix devraient être possible, utiliser une biblio bundlée, utiliser une biblio dans la version N et enfin utiliser une biblio dans sa version à jour. Avec un système de repo et de dépendances repensé, ça résoudrait bien des problèmes.

Windows fait un peu ça. Tu peux soit bundler statiquement (si la lib existe en ce format), soit dynamiquement à une version donnée, soit avec la dernière possible. C'est ce qu'il y a de mieux dans ce qu'on fait actuellement je pense, mais ça pose quand même 2 soucis qui ne rendent pas la solution idéale :
1) Au final on ne sait pas si des applis utilisent encore de vieilles versions et donc ont potentiellement des soucis de sécurité (problème solvable avec un bon soft permettant de grapher les dépendances),
2) L'appli doit savoir si elle continuera à fonctionner avec les updates des libs ou si doit se figer sur la version actuelle. Bien que la réputation aide à déterminer ça, c'est quand même assez boiteux.

Je dirais qu'il est inévitable de devoir mettre à jour le système, entraînant des incompatibilité avec les apps existantes. Pour moi deux choses sont importantes, mettre à jour une app ne doit pas en casser une autre, et mettre à jour le système ne doit pas casser les apps, SAUF dans le cas des mises à jour majeures.
Si les mises à jour mineures risquent de péter ton environnement comme c'est le cas avec la philosophie Linux, alors les gens ne les font plus (trop risqué) et elles perdent tout leur intérêt. De la même manière, si ces mises à jour "majeures" sont trop fréquentes (plus d'une fois par an je dirais, voire 6 mois pour un système qui se définit comme expérimental), alors ça ne se justifie pas : si ce n'est plus un "événement" alors il devient difficile de trouver les informations permettant de savoir s'il est ok de migrer ou pas pour chaque version, et les développeurs commencent à en avoir marre de s'adapter trop souvent.

Windows par exemple, garantit la compatibilité pour une version du système d'exploitation (la seule exception ayant été XP SP2, et on se rappelle le tollé que ça a fait...), et seulement au moment de migrer alors il faut se poser la question de ce qui marche encore et ce qui ne marche plus. Faire ce travail tous les trois ans me paraît acceptable, surtout que le nouveau système est d'abord testé dans une VM ou une partition séparée.

Folco (./7536) :

flanker (./7534) :
et qu'elle soit compatible avec tous les logiciels installés

C'est la distribution qui est en charge de ça.

(C'est pour ça que je préfère les distributions mainstream, plutôt que la foultitude d'autres éclosant sur DistroWatch tous les jours, "basées sur XYZ", mais ne packageant que 10% des softs fournis à la base, et obligeant à crawler dans des repos qui ne vont jamais coller ensemble)

Justement, parfois on a besoin d'une version particulière d'une lib ou tu n'es pas root... Et c'est là que ça pose problème.

Tu te situes dans le cadre idéal (tu es root, avec une connexion internet, dans le pire des cas tu as un compilateur, et tu n'installes pas les libs mais les programmes). Alors forcément, tu ne vois pas les inconvénients...

flanker (./7534) :

Kevin Kofler (./7531) :
Le problème est que tes arguments ont déjà été cités ici une dizaine de fois et que ça ne les rend pas plus vrais: Par exemple, le problème de simplicité d'installation est un faux problème quand apt/yum/… te télécharge automatiquement toutes les dépendances sans que tu aies à t'en soucier. Et pour le reste:

Mouais, mouais... Tu passes volontairement sous silence les inconvénients du système : il faut être connecté à internet, être root, que la version voulue soit disponible, et qu'elle soit compatible avec tous les logiciels installés... Mais bon, on a l'habitude avec toi.

Le système de dépendance pourrait très bien installer plusieurs versions d'une librairie dans le répertoire /usr/lib*. Le linker de librairies dynamiques le gère très bien. C'est juste qu'aucune distribution ne le fait vraiment, et je pense que c'est bien dommage d'ailleurs.

flanker (./7539) :
Tu te situes dans le cadre idéal (tu es root, avec une connexion internet, dans le pire des cas tu as un compilateur, et tu n'installes pas les libs mais les programmes). Alors forcément, tu ne vois pas les inconvénients...

C'est ptêt pour ça que depuis le début, je dis que ça dépend du cas de figure dans lequel on se place ? C'est pas moi qui braille "oué mais les dépendances c'est absolument nul à chier vu que c'est la solution linux gnagnagna, LA solution propre c'est celle-là [...]"

Si ce n'était qu'une question de droits et de connexion internet...

vince &

Brunni (./7529) :
Je sais même pas pourquoi je prends la peine de développer mon point de vue pour avoir pour toute clôture de discussion une réponse équivalente à "de toute façon t'es con" (autrement dit, je n'ai pas cité une seule fois Apple concernant ce sujet ; c'est comme si on discutais et quand j'arrive à court d'argument je te sors "oh et puis ta sÅ“ur elle est moche donc t'as tort").

Bha quand on voit ça :

Brunni (./7525) :
C'est comme si je te disais que je suis content que ma bagnole soit en panne tout le temps, ça me permet de progresser en mécanique ; même si ça me convient, une bagnole qui est toujours en panne c'est de la merde, point barre.

qui veut à quelque chose près dire "tout ce qui n'est pas Apple tombe tout le temps en panne, et ce qui tombe toujours en panne c'est de la merde" (bon certes dans ton système d'appréciation OS X > windows > nux, windows n'étant qu'à moitié de la merde ), on est tellement sur le cul par la qualité de ton argumentation, qui déblatère des affirmations péremptoires hors de toute réalité (linux est justement beaucoup utilisé pour les systèmes qui ont besoin de fiabilité, lolol ), qu'on a simplement envie de te renvoyer le miroir.

Mais bon je sais pas on devrait simplement arrêter de discuter avec les sectataires de Jobs, car à chaque débat cela apparait de plus en plus dénué de tout intérêt.

flanker (./7534) :
Tu passes volontairement sous silence les inconvénients du système : il faut être connecté à internet,

1. Une trivialité de nos jours.
2. Et tes app bundles, tu les transfères par signaux de fumée?

être root,

1. Un simple utilisateur n'a pas à installer des logiciels, c'est le boulot de l'administrateur.
2. Si l'administrateur n'est pas d'accord avec le point précédent, il n'a qu'à donner la permission PolicyKit org.freedesktop.packagekit.package-install qui permet justement d'installer des logiciels (signés, depuis un dépôt déjà configuré).
3. Et enfin, si le but est de donner à l'utilisateur les pleins droits dans un espace isolé, c'est à ça que servent les machines virtuelles.

que la version voulue soit disponible,

C'est le boulot de la distribution, et sinon il y a les dépôts tiers (PPAs) aussi. Bien sûr, si on met sa distribution à jour seulement une fois par décennie, il ne faut pas s'attendre à avoir des logiciels à jour dans les dépôts officiels.

et qu'elle soit compatible avec tous les logiciels installés...

Ça aussi, c'est le boulot de la distribution.

very (./7543) :
Mais bon je sais pas on devrait simplement arrêter de discuter avec les sectataires de Jobs, car à chaque débat cela apparait de plus dénué de tout intérêt.

+1

squalyl (./7535) :
apt et yum ne permettent pas d'affecter une version particulière d'une lib partagée à une appli.

Si, mais seulement là où ça a un sens et où ça a donc été prévu par la distribution sous forme de bibliothèque de compatibilité.

PpHd (./7540) :
Le système de dépendance pourrait très bien installer plusieurs versions d'une librairie dans le répertoire /usr/lib*. Le linker de librairies dynamiques le gère très bien. C'est juste qu'aucune distribution ne le fait vraiment, et je pense que c'est bien dommage d'ailleurs.

Les bibliothèques de compatibilité sont à éviter au possible à cause des conflits de symboles. Imagine que appA linke libB et libC, que libB linke libD.so.1 et libC linke libD.so.2. Les symboles des 2 versions incompatibles de libD entreront en conflit dans appA, causant un comportement en général imprévisible. Donc partout où c'est possible, il vaut mieux patcher tous les logiciels pour fonctionner avec la version la plus récente d'une bibliothèque et éviter ainsi la DLL Hell.

Kevin Kofler (./7544) :
2. Et tes app bundles, tu les transfères par signaux de fumée?

Les clés USB et les disques externes, tu connais ?

Quand au reste…

Kevin Kofler (./7545) :
Les bibliothèques de compatibilité sont à éviter au possible à cause des conflits de symboles. Imagine que appA linke libB et libC, que libB linke libD.so.1 et libC linke libD.so.2. Les symboles des 2 versions incompatibles de libD entreront en conflit dans appA, causant un comportement en général imprévisible. Donc partout où c'est possible, il vaut mieux patcher tous les logiciels pour fonctionner avec la version la plus récente d'une bibliothèque et éviter ainsi la DLL Hell.

Non, car dans ce cas ca aurait été mal fait à la base dans la distribution puisque tu aurais empaquetés appA qui tire 2 versions de libD.

Mon rêve serait d'avoir une distribution où toutes les apps et librairies seraient versionnées et on pourrait installer n'importe quelle version de n'importe application sur ta distrib (dans la limite du raisonnable et avec de gros warnings "unsafe") et pas juste la dernière "stable" de la distribution. Et toute installable en même temps bien sûr (dans la limite du raisonnable).

PpHd (./7547) :
Non, car dans ce cas ca aurait été mal fait à la base dans la distribution puisque tu aurais empaquetés appA qui tire 2 versions de libD.

Justement, c'est très compliqué de vérifier toutes les dépendances indirectes, d'autant plus qu'il y a aussi dlopen qui peut en cacher une partie. On a déjà eu plusieurs cas qui nous ont échappés, le plus récent: https://bugzilla.redhat.com/show_bug.cgi?id=914634. Plus vite une bibliothèque de compatibilité dégage, mieux c'est (et idéalement elle n'est pas créée du tout)!

Mon rêve serait d'avoir une distribution où toutes les apps et librairies seraient versionnées et on pourrait installer n'importe quelle version de n'importe application sur ta distrib (dans la limite du raisonnable et avec de gros warnings "unsafe") et pas juste la dernière "stable" de la distribution. Et toute installable en même temps bien sûr (dans la limite du raisonnable).

Il faudrait modifier le comportement de ld.so (voire la spécification ELF) pour ça (activer le deep binding par défaut, au moins).

PpHd : essaie déjà de convaincre un Linuxien qu'avoir une API stable* est une bonne chose, qu'on rigole

Kevin Kofler (./7548) :
Justement, c'est très compliqué de vérifier toutes les dépendances indirectes, d'autant plus qu'il y a aussi dlopen qui peut en cacher une partie. On a déjà eu plusieurs cas qui nous ont échappés, le plus récent: https://bugzilla.redhat.com/show_bug.cgi?id=914634. Plus vite une bibliothèque de compatibilité dégage, mieux c'est (et idéalement elle n'est pas créée du tout)!

En quoi c'est compliqué d'enregistrer avec quelle version de la librairie ca a été compilée et testée ?
Le problème du dlopen existe déjà et il faut déjà le résoudre.

Zerosquare (./7549) :
PpHd : essaie déjà de convaincre un Linuxien qu'avoir une API stable* est une bonne chose, qu'on rigole

Je connais des centaines de linuxiens qui pensent que c'est une bonne chose

PpHd (./7550) :
En quoi c'est compliqué d'enregistrer avec quelle version de la librairie ca a été compilée et testée ?

Parce qu'entretemps, une bibliothèque dont ça dépend peut avoir été recompilé avec une nouvelle version d'une autre bibliothèque, qui est aussi une dépendance indirecte à travers un autre chemin et du coup on mélange plusieurs version incompatibles sans s'en rendre compte.

Le problème du dlopen existe déjà et il faut déjà le résoudre.

La solution, c'est de ne pas avoir plusieurs bibliothèques qui exportent les mêmes symboles.

PpHd (./7551) :
Je connais des centaines de linuxiens qui pensent que c'est une bonne chose

Ça ne fait malheureusement pas des masses par rapport à ceux qui pensent le contraire

A parce qu'en plus d'utiliser des softs merdiques, les linuxiens sont pratiquement tous cons ?

non, y'a ni plus moins de cons que sur les autres OS (et en grande majorité, c'est pas à cause de leur OS qu'ils sont devenus cons)

very (./7543) :
Bha quand on voit ça :

Brunni (./7525) :
C'est comme si je te disais que je suis content que ma bagnole soit en panne tout le temps, ça me permet de progresser en mécanique ; même si ça me convient, une bagnole qui est toujours en panne c'est de la merde, point barre.

qui veut à quelque chose près dire "tout ce qui n'est pas Apple tombe tout le temps en panne, et ce qui tombe toujours en panne c'est de la merde" (bon certes dans ton système d'appréciation OS X > windows > nux, windows n'étant qu'à moitié de la merde ), on est tellement sur le cul par la qualité de ton argumentation, qui déblatère des affirmations péremptoires hors de toute réalité (linux est justement beaucoup utilisé pour les systèmes qui ont besoin de fiabilité, lolol ), qu'on a simplement envie de te renvoyer le miroir.

Mais bon je sais pas on devrait simplement arrêter de discuter avec les sectataires de Jobs, car à chaque débat cela apparait de plus en plus dénué de tout intérêt.

Tu n'as… rien compris. Mais j'ai l'impression que tu es assez spécialiste pour sortir les choses de leur contexte.

(En plus pour Folco c'est assez soulant cette supposition que je soutiens forcément Apple dans tout ce que je dis, déjà de 1 j'en ai pas parlé du tout dans ce sujet donc utiliser ça dans ton argumentation la rend absolument ridicule (je tiens à le dire une fois, je le pense à chaque post), et de 2 je vois pas pourquoi j'aurais à me justifier quand je critique un point sur Linux ; ce système mérite de se poser des questions quand même, quand tu vois que malgré la gratuité il est à 1% de part de marché dans sa forme actuelle, alors que si on corrigeait justement ces défauts de distro et faisait... au hasard Android, alors on aurait peut être au moins une partie des 70% de pdm de ce dernier. En plus quand t'as autant de power users qui en disent du mal et retournent vers des systèmes proprios restrictifs, alors c'est qu'il y a quand même un problème non ?)

Kevin Kofler (./7552) :

PpHd (./7550) :
En quoi c'est compliqué d'enregistrer avec quelle version de la librairie ca a été compilée et testée ?

Parce qu'entretemps, une bibliothèque dont ça dépend peut avoir été recompilé avec une nouvelle version d'une autre bibliothèque, qui est aussi une dépendance indirecte à travers un autre chemin et du coup on mélange plusieurs version incompatibles sans s'en rendre compte.

Oui mais dans ce cas tant que l'application elle même n'a pas été recompilée avec la bibliothèque recompilée, elle utilise toujours la version initiale.

Le problème du dlopen existe déjà et il faut déjà le résoudre.

La solution, c'est de ne pas avoir plusieurs bibliothèques qui exportent les mêmes symboles.

C'est une solution, mais pas de ce problème là

Zerosquare (./7553) :

PpHd (./7551) :
Je connais des centaines de linuxiens qui pensent que c'est une bonne chose

Ça ne fait malheureusement pas des masses par rapport à ceux qui pensent le contraire

Ca fait beaucoup par rapport à ceux que je connais

PpHd (./7540) :
Le système de dépendance pourrait très bien installer plusieurs versions d'une librairie dans le répertoire /usr/lib*. Le linker de librairies dynamiques le gère très bien. C'est juste qu'aucune distribution ne le fait vraiment, et je pense que c'est bien dommage d'ailleurs.

[pub] Gentoo et ses slots (entres autres) [/pub]

Kevin Kofler (./7544) :
PolicyKit

Haaa les *Kit de Redhat.. Quelles belles merdes et foutage de gueule de RedHat ça encore. Ils foutent en l'air de nombreux projets bien meilleurs que les leurs juste avec toutes ces merdes (et systemd)

Zerosquare (./7553) :
Ça ne fait malheureusement pas des masses par rapport à ceux qui pensent le contraire

Surtout ce ne sotn pas des gens qui gerent les projets "libres" (quelqu'un pour aller taper linus a ce sujet ? non parceque le premier responsable c'est encore lui avec l'ABI kernel totalement instable..)

PpHd (./7557) :

Kevin Kofler (./7552) :

PpHd (./7550) :
En quoi c'est compliqué d'enregistrer avec quelle version de la librairie ca a été compilée et testée ?

Parce qu'entretemps, une bibliothèque dont ça dépend peut avoir été recompilé avec une nouvelle version d'une autre bibliothèque, qui est aussi une dépendance indirecte à travers un autre chemin et du coup on mélange plusieurs version incompatibles sans s'en rendre compte.

Oui mais dans ce cas tant que l'application elle même n'a pas été recompilée avec la bibliothèque recompilée, elle utilise toujours la version initiale.

Non, pas dans le cas de figure d'une dépendance indirecte:

Kevin Kofler (./7545) :
Imagine que appA linke libB et libC, que libB linke libD.so.1 et libC linke libD.so.2.

La libC de mon exemple peut passer de la libD.so.1 à la libD.so.2 sans que le soname de la libC change et donc sans qu'appA s'en rende compte, et du coup des conflits de symboles sont introduits! C'est ça le cas de figure qui a produit les bogues que j'ai eu l'occasion de recontrer.