Posté par karteum59 (site web personnel) .
En réponse au journal Sans OS.
Évalué à 6.
Dernière modification le 17 décembre 2014 à 01:32.
En fait, on est en train de mélanger les sujets
il est légitime que le "système de base" (kernel, drivers, libc, xorg, pa...) soit stable. Il est aussi légitime que la mise à jour d'une appli ne puisse rien casser d'autre que l'appli elle-même
l'utilisateur souhaite que ses jeux, son firefox, ses outils de dev, etc. soient dans une version récente (comme c'est le cas sous Mac/Win, dont le système de base n'est pas en rolling-release pour autant)
Les applis ont des dépendances. En rolling-release, peut-être que mettre à jour l'appX va nécessiter de mettre à jour la libY et qu'il faut donc aussi mettre à jour (ou casser) d'autres applis au passage qui n'étaient pas mûres ou dont l'utilisateur ne souhaitait pas l'upgrade. Donc une distro stable comme Debian a nécessairement des couplages assez forts (d'autant plus qu'il y a de paquets dans main). Mac/Win résolvent en partie le problème de manière radicale: chaque appli embarque ses .dll ! (ce qui outre la consommation d'espace disque, complique la correction des failles de sécu tout en étant moins efficace que le link statique). Peut-être qu'une approche intermédiaire serait de permettre à plusieurs versions d'une lib de coexister, de stocker chaque appli dans un dossier/chroot dédié, et de gérer quelle appli utilise quelle version de lib à coup de symlink/hardlink dans ledit dossier. A ce sujet, Nix semble fort sympathique ("You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the "DLL hell". Because of the hashing scheme, different versions of a package end up in different paths in the Nix store, so they don’t interfere with each other."), de même que 0install ("If two programs want the same version of a library, they'll share it. Otherwise, they'll use separate copies").
j'aimerais bien voir, pour un logiciel "classique", la Feature qui n'existe QUE sous la dernière version
Il me semble que c'est à l'utilisateur d'en juger et non au développeur d'être donneur de leçons "dis moi ton besoin, je te dirai comment t'en passer".
Note que ça n'est pas nécessairement une "feature" mais ça peut être un bug corrigé, etc. Au hasard: si tu fais du dev django, tu utilises la version de Debian Stable, ou bien celle fournie par pip ? (question évidemment transposable à rails, nodejs ou à ton_framework_préféré).
[^] # Re: Probablement bientôt?!
Posté par karteum59 (site web personnel) . En réponse au journal Sans OS. Évalué à 6. Dernière modification le 17 décembre 2014 à 01:32.
En fait, on est en train de mélanger les sujets
Les applis ont des dépendances. En rolling-release, peut-être que mettre à jour l'appX va nécessiter de mettre à jour la libY et qu'il faut donc aussi mettre à jour (ou casser) d'autres applis au passage qui n'étaient pas mûres ou dont l'utilisateur ne souhaitait pas l'upgrade. Donc une distro stable comme Debian a nécessairement des couplages assez forts (d'autant plus qu'il y a de paquets dans main). Mac/Win résolvent en partie le problème de manière radicale: chaque appli embarque ses .dll ! (ce qui outre la consommation d'espace disque, complique la correction des failles de sécu tout en étant moins efficace que le link statique). Peut-être qu'une approche intermédiaire serait de permettre à plusieurs versions d'une lib de coexister, de stocker chaque appli dans un dossier/chroot dédié, et de gérer quelle appli utilise quelle version de lib à coup de symlink/hardlink dans ledit dossier. A ce sujet, Nix semble fort sympathique ("You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the "DLL hell". Because of the hashing scheme, different versions of a package end up in different paths in the Nix store, so they don’t interfere with each other."), de même que 0install ("If two programs want the same version of a library, they'll share it. Otherwise, they'll use separate copies").
Il me semble que c'est à l'utilisateur d'en juger et non au développeur d'être donneur de leçons "dis moi ton besoin, je te dirai comment t'en passer".
Note que ça n'est pas nécessairement une "feature" mais ça peut être un bug corrigé, etc. Au hasard: si tu fais du dev django, tu utilises la version de Debian Stable, ou bien celle fournie par pip ? (question évidemment transposable à rails, nodejs ou à ton_framework_préféré).