J'utilise régulièrement LINUX depuis près d'un an, et il y a quelque chose
qui m'énerve régulièrement : les dépendances de paquetages.
Certes, si on utilise ceux d'une distribution, tout va bien. Mais nulle
distribution, aussi complète soit-elle, ne peut prétendre disposer de tous
les paquetages qui existent et dont on a besoin. On va donc les chercher
sur Internet, et c'est là que le parcours du combattant commence, qu'on
utilise les sources ou des RPM.
Pour installer (ou compiler) tel logiciel, on a besoin de tel autre
paquetage, en tel version. Qui à son tour demandera un autre paquetage,
etc...
Si je peux comprendre pourquoi un développeur ne veux pas réinventer la
roue, c'est à dire écrire une nouvelle librairie de fonctions alors qu'elle
existe déjà, pourquoi certains ne la fournissent-il pas dans le paquetage ?
Ou au moins, ne mettent-ils pas un lien pour dire où la télécharger ?
Bref, s'il n'est nul besoin de réinventer la roue à chaque fois, au moins
doit-on la fournir !
Le Sun, 18 Jul 2004 23:40:56 +0200 après l'an de grâce, inspiré(e) Jerome Lambert écrivait la plume légère :
Effectivement il n'a critiqué personne par contre il part sur un mauvais réflexe : celui que les développeurs lui devraient quelque chose. Il y a un fossé entre le monde du logiciel propriétaire qui est basé sur l'abétissement des utilisateurs qui perdent tout sens critique tant sur les outils qu'ils utilisent que sur leur propre pratique au profit d'une démarche de«consommateurs» : je ne veux rien comprendre, je ne veux rien faire mais je veux que ça marche.
Démarche normale, me semble-t-il... Démarche normale quand tu es un consommateurs de logiciels propriétaires
que tu as payé. Tu ne l'as peut être par remarqué mais le logiciel li bre n'est pas dans la sphère marchande.
Que tu connaisses esr c'est bien, mais il faudrait lire son site jusqu'au bout si tu veux t'assurer de ne pas avoir de réponses sèches aux questions que tu poses : http://www.catb.org/~esr/faqs/smart-questions.html
Ma voiture doit m'enmener d'un point à un autre, sans que je sois mécanicien expériementé...
Le logiciel libre n'est pas une voiture achetée à un garagiste !
**Il n'y a pas d'acte d'achat, et la licence te livre le produit *AS IS* (en l'état) ** : personne ne s'engage à quoi que ce soit, et il n'y a pas de garantie.
...
J'espère que vous n'êtes pas développeur, parce qu'avec un mentalit é pareille...
pire que ça j'ai même fait du support pour du logiciel libre, et j'ai
aussi travaillé en société de service en logiciel libre.
Julien
Le Sun, 18 Jul 2004 23:40:56 +0200 après l'an de grâce, inspiré(e)
Jerome Lambert <jerome.lambert@swing.be> écrivait la plume légère :
Effectivement il n'a critiqué personne par contre il part sur un
mauvais réflexe : celui que les développeurs lui devraient quelque
chose. Il y a un fossé entre le monde du logiciel propriétaire qui
est basé sur l'abétissement des utilisateurs qui perdent tout sens
critique tant sur les outils qu'ils utilisent que sur leur propre
pratique au profit d'une démarche de«consommateurs» : je ne veux
rien comprendre, je ne veux rien faire mais je veux que ça marche.
Démarche normale, me semble-t-il...
Démarche normale quand tu es un consommateurs de logiciels propriétaires
que tu as payé. Tu ne l'as peut être par remarqué mais le logiciel li bre
n'est pas dans la sphère marchande.
Que tu connaisses esr c'est bien, mais il faudrait lire son site
jusqu'au bout si tu veux t'assurer de ne pas avoir de réponses sèches
aux questions que tu poses :
http://www.catb.org/~esr/faqs/smart-questions.html
Ma voiture doit m'enmener d'un point à un autre, sans que je sois
mécanicien expériementé...
Le logiciel libre n'est pas une voiture achetée à un garagiste !
**Il n'y a pas d'acte d'achat, et la licence te livre le produit *AS
IS* (en l'état) ** : personne ne s'engage à quoi que ce soit, et il n'y
a pas de garantie.
...
J'espère que vous n'êtes pas développeur, parce qu'avec un mentalit é
pareille...
pire que ça j'ai même fait du support pour du logiciel libre, et j'ai
aussi travaillé en société de service en logiciel libre.
Le Sun, 18 Jul 2004 23:40:56 +0200 après l'an de grâce, inspiré(e) Jerome Lambert écrivait la plume légère :
Effectivement il n'a critiqué personne par contre il part sur un mauvais réflexe : celui que les développeurs lui devraient quelque chose. Il y a un fossé entre le monde du logiciel propriétaire qui est basé sur l'abétissement des utilisateurs qui perdent tout sens critique tant sur les outils qu'ils utilisent que sur leur propre pratique au profit d'une démarche de«consommateurs» : je ne veux rien comprendre, je ne veux rien faire mais je veux que ça marche.
Démarche normale, me semble-t-il... Démarche normale quand tu es un consommateurs de logiciels propriétaires
que tu as payé. Tu ne l'as peut être par remarqué mais le logiciel li bre n'est pas dans la sphère marchande.
Que tu connaisses esr c'est bien, mais il faudrait lire son site jusqu'au bout si tu veux t'assurer de ne pas avoir de réponses sèches aux questions que tu poses : http://www.catb.org/~esr/faqs/smart-questions.html
Ma voiture doit m'enmener d'un point à un autre, sans que je sois mécanicien expériementé...
Le logiciel libre n'est pas une voiture achetée à un garagiste !
**Il n'y a pas d'acte d'achat, et la licence te livre le produit *AS IS* (en l'état) ** : personne ne s'engage à quoi que ce soit, et il n'y a pas de garantie.
...
J'espère que vous n'êtes pas développeur, parce qu'avec un mentalit é pareille...
pire que ça j'ai même fait du support pour du logiciel libre, et j'ai
aussi travaillé en société de service en logiciel libre.
Julien
Benjamin FRANCOIS
Johan s'est exprimé en ces termes:
sur une debian "man apt"
Je doute que ça l'aide beaucoup.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Johan s'est exprimé en ces termes:
sur une debian "man apt"
Je doute que ça l'aide beaucoup.
--
http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Benjamin FRANCOIS
Michel Talon s'est exprimé en ces termes:
Ton apt-get ressemble à un vrai système de paquetage comme de la bière light à de la bière.
Pour les mous du bulbe, il y a Synaptic. On le lance, on voit dans la colonne de gauche "KDE Desktop Environment", on clique dessus, on voit dans la colonne de droite "kde", on coche la case, et ça installe non seulement tout KDE mais aussi X. En utilisant apt-get derrière.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Michel Talon s'est exprimé en ces termes:
Ton apt-get ressemble à un vrai système de paquetage comme de la bière
light à de la bière.
Pour les mous du bulbe, il y a Synaptic. On le lance, on voit dans la
colonne de gauche "KDE Desktop Environment", on clique dessus, on voit
dans la colonne de droite "kde", on coche la case, et ça installe non
seulement tout KDE mais aussi X. En utilisant apt-get derrière.
--
http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Ton apt-get ressemble à un vrai système de paquetage comme de la bière light à de la bière.
Pour les mous du bulbe, il y a Synaptic. On le lance, on voit dans la colonne de gauche "KDE Desktop Environment", on clique dessus, on voit dans la colonne de droite "kde", on coche la case, et ça installe non seulement tout KDE mais aussi X. En utilisant apt-get derrière.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Benjamin FRANCOIS
Denis s'est exprimé en ces termes:
Je suis très content de ma Mandrake.
La preuve que non, puisque tu viens t'en plaindre sur fcold.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Denis s'est exprimé en ces termes:
Je suis très content de ma Mandrake.
La preuve que non, puisque tu viens t'en plaindre sur fcold.
--
http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
La preuve que non, puisque tu viens t'en plaindre sur fcold.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
talon
Benjamin FRANCOIS wrote:
Michel Talon s'est exprimé en ces termes:
Ton apt-get ressemble à un vrai système de paquetage comme de la bière light à de la bière.
Pour les mous du bulbe, il y a Synaptic. On le lance, on voit dans la colonne de gauche "KDE Desktop Environment", on clique dessus, on voit dans la colonne de droite "kde", on coche la case, et ça installe non seulement tout KDE mais aussi X. En utilisant apt-get derrière.
Comme tu dis ça utilise apt donc rien ne marche mieux qu'avec apt directement. Le seul avantage est que ça te fournit le nom des paquets, mais quand tu auras une liste plate de 15000 paquets tu seras bien avancé. Le problème est que faire un bon système de paquetage est trés difficile, des tas de projets se cassent les dents dessus depuis des années, et ce n'est pas par des incantations comme les tiennes -apt est magique, la faute aux cons quand ça ne marche pas- que la situation va s'améliorer. Au contraire, les gens comme toi, qui prétendent que tout va bien quand tout va mal, sont le principal obstacle au progrés. La méthode Coué ne parviendra jamais à renverser l'évidence absolue du fait que si la méthode Debian était si formidable, la quasi totalité des utilisateurs Linux seraient sous Debian, alors qu'ils sont sous RedHat, Suse et Mandrake. Et les quelques distributions alternatives commerciales basées sur le système Debian fournissent leurs propres paquets.
--
Michel TALON
Benjamin FRANCOIS <kwyxz@kwyxz.org> wrote:
Michel Talon s'est exprimé en ces termes:
Ton apt-get ressemble à un vrai système de paquetage comme de la bière
light à de la bière.
Pour les mous du bulbe, il y a Synaptic. On le lance, on voit dans la
colonne de gauche "KDE Desktop Environment", on clique dessus, on voit
dans la colonne de droite "kde", on coche la case, et ça installe non
seulement tout KDE mais aussi X. En utilisant apt-get derrière.
Comme tu dis ça utilise apt donc rien ne marche mieux qu'avec apt directement.
Le seul avantage est que ça te fournit le nom des paquets, mais quand tu
auras une liste plate de 15000 paquets tu seras bien avancé. Le problème
est que faire un bon système de paquetage est trés difficile, des tas de
projets se cassent les dents dessus depuis des années, et ce n'est pas par
des incantations comme les tiennes -apt est magique, la faute aux cons quand
ça ne marche pas- que la situation va s'améliorer. Au contraire, les gens
comme toi, qui prétendent que tout va bien quand tout va mal, sont le
principal obstacle au progrés. La méthode Coué ne parviendra jamais à
renverser l'évidence absolue du fait que si la méthode Debian était si
formidable, la quasi totalité des utilisateurs Linux seraient sous Debian,
alors qu'ils sont sous RedHat, Suse et Mandrake. Et les quelques distributions
alternatives commerciales basées sur le système Debian fournissent leurs
propres paquets.
Ton apt-get ressemble à un vrai système de paquetage comme de la bière light à de la bière.
Pour les mous du bulbe, il y a Synaptic. On le lance, on voit dans la colonne de gauche "KDE Desktop Environment", on clique dessus, on voit dans la colonne de droite "kde", on coche la case, et ça installe non seulement tout KDE mais aussi X. En utilisant apt-get derrière.
Comme tu dis ça utilise apt donc rien ne marche mieux qu'avec apt directement. Le seul avantage est que ça te fournit le nom des paquets, mais quand tu auras une liste plate de 15000 paquets tu seras bien avancé. Le problème est que faire un bon système de paquetage est trés difficile, des tas de projets se cassent les dents dessus depuis des années, et ce n'est pas par des incantations comme les tiennes -apt est magique, la faute aux cons quand ça ne marche pas- que la situation va s'améliorer. Au contraire, les gens comme toi, qui prétendent que tout va bien quand tout va mal, sont le principal obstacle au progrés. La méthode Coué ne parviendra jamais à renverser l'évidence absolue du fait que si la méthode Debian était si formidable, la quasi totalité des utilisateurs Linux seraient sous Debian, alors qu'ils sont sous RedHat, Suse et Mandrake. Et les quelques distributions alternatives commerciales basées sur le système Debian fournissent leurs propres paquets.
--
Michel TALON
Benjamin FRANCOIS
Michel Talon s'est exprimé en ces termes:
Comme tu dis ça utilise apt donc rien ne marche mieux qu'avec apt directement. Le seul avantage est que ça te fournit le nom des paquets, mais quand tu auras une liste plate de 15000 paquets tu seras bien avancé.
C'est déjà subdivisé en catégories, il suffira de faire un deuxième niveau de catégories. Si l'utilisateur de base n'est pas perdu en cli- quant sur le menu "Démarrer" de XP que je trouve fouillis au possible, ça ne le changera pas beaucoup.
Au contraire, les gens comme toi, qui prétendent que tout va bien quand tout va mal, sont le principal obstacle au progrés.
C'est vrai que c'est beaucoup mieux de crier en permanence que tout va mal sauf chez un BSD dont le nom commence par Free.
La méthode Coué ne parviendra jamais à renverser l'évidence absolue du fait que si la méthode Debian était si formidable, la quasi totalité des utilisateurs Linux seraient sous Debian, alors qu'ils sont sous RedHat, Suse et Mandrake.
Et on constate que ces distributions commencent à proposer des outils équivalents à apt, quand ce n'est pas carrément apt.
Et les quelques distributions alternatives commerciales basées sur le système Debian fournissent leurs propres paquets.
Et ça n'a pas de rapport avec la choucroute, elles utilisent toujours apt derrière.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Michel Talon s'est exprimé en ces termes:
Comme tu dis ça utilise apt donc rien ne marche mieux qu'avec apt directement.
Le seul avantage est que ça te fournit le nom des paquets, mais quand tu
auras une liste plate de 15000 paquets tu seras bien avancé.
C'est déjà subdivisé en catégories, il suffira de faire un deuxième
niveau de catégories. Si l'utilisateur de base n'est pas perdu en cli-
quant sur le menu "Démarrer" de XP que je trouve fouillis au possible,
ça ne le changera pas beaucoup.
Au contraire, les gens
comme toi, qui prétendent que tout va bien quand tout va mal, sont le
principal obstacle au progrés.
C'est vrai que c'est beaucoup mieux de crier en permanence que tout va
mal sauf chez un BSD dont le nom commence par Free.
La méthode Coué ne parviendra jamais à
renverser l'évidence absolue du fait que si la méthode Debian était si
formidable, la quasi totalité des utilisateurs Linux seraient sous Debian,
alors qu'ils sont sous RedHat, Suse et Mandrake.
Et on constate que ces distributions commencent à proposer des outils
équivalents à apt, quand ce n'est pas carrément apt.
Et les quelques distributions
alternatives commerciales basées sur le système Debian fournissent leurs
propres paquets.
Et ça n'a pas de rapport avec la choucroute, elles utilisent toujours
apt derrière.
--
http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Comme tu dis ça utilise apt donc rien ne marche mieux qu'avec apt directement. Le seul avantage est que ça te fournit le nom des paquets, mais quand tu auras une liste plate de 15000 paquets tu seras bien avancé.
C'est déjà subdivisé en catégories, il suffira de faire un deuxième niveau de catégories. Si l'utilisateur de base n'est pas perdu en cli- quant sur le menu "Démarrer" de XP que je trouve fouillis au possible, ça ne le changera pas beaucoup.
Au contraire, les gens comme toi, qui prétendent que tout va bien quand tout va mal, sont le principal obstacle au progrés.
C'est vrai que c'est beaucoup mieux de crier en permanence que tout va mal sauf chez un BSD dont le nom commence par Free.
La méthode Coué ne parviendra jamais à renverser l'évidence absolue du fait que si la méthode Debian était si formidable, la quasi totalité des utilisateurs Linux seraient sous Debian, alors qu'ils sont sous RedHat, Suse et Mandrake.
Et on constate que ces distributions commencent à proposer des outils équivalents à apt, quand ce n'est pas carrément apt.
Et les quelques distributions alternatives commerciales basées sur le système Debian fournissent leurs propres paquets.
Et ça n'a pas de rapport avec la choucroute, elles utilisent toujours apt derrière.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Benjamin FRANCOIS
Shmurtz s'est exprimé en ces termes:
Si ne pas se plaindre sur fcold veut dire qu'on est dans la béatitude complète, je n'ose imaginer le nombre d'imbéciles heureux avec leur distrib.
Le problème dans son cas, c'est surtout qu'il a un souci avec RPM et qu'entre les RPM de Red Hat, de Mandrake, de SuSE, de Connectiva, que quand on en installe un p'tet je casse tout, p'tet pas, c'est tout de même assez spécifique. Jamais eu ce souci en installant *un* package de Knoppix sur une Deb, voire même de Corel sur une Deb, ou l'inverse.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Shmurtz s'est exprimé en ces termes:
Si ne pas se plaindre sur fcold veut dire qu'on est dans la béatitude
complète, je n'ose imaginer le nombre d'imbéciles heureux avec leur
distrib.
Le problème dans son cas, c'est surtout qu'il a un souci avec RPM et
qu'entre les RPM de Red Hat, de Mandrake, de SuSE, de Connectiva, que
quand on en installe un p'tet je casse tout, p'tet pas, c'est tout de
même assez spécifique. Jamais eu ce souci en installant *un* package de
Knoppix sur une Deb, voire même de Corel sur une Deb, ou l'inverse.
--
http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
Si ne pas se plaindre sur fcold veut dire qu'on est dans la béatitude complète, je n'ose imaginer le nombre d'imbéciles heureux avec leur distrib.
Le problème dans son cas, c'est surtout qu'il a un souci avec RPM et qu'entre les RPM de Red Hat, de Mandrake, de SuSE, de Connectiva, que quand on en installe un p'tet je casse tout, p'tet pas, c'est tout de même assez spécifique. Jamais eu ce souci en installant *un* package de Knoppix sur une Deb, voire même de Corel sur une Deb, ou l'inverse.
-- http://www.kwyxz.org - Now reopened, with 20% more bullshitting !
talon
Shmurtz wrote:
les options de dpkg sont pas mal non plus.:-)
Oui c'est de ça que je parlais en fait plutôt que de apt lui même. En soi apt est neutre par rapport au système de paquetage, et il y a même une distribution BSD (dflybsd) qui envisage de l'utiliser. Le problème n'est pas là, le problème est comment faire coexister plusieurs dépendances contradictoires, de façon que le problème de "stabilité" au sens de Debian (c'est à dire la cohérence entre les paquets) ne se pose pas. Pour résoudre ce problème il faut des techniques allant trés au delà du système de paquetage, et même éventuellement des aides de l'OS (c'est aussi ce qui est envisagé pour dflybsd - autrement dit que deux programmes différents voient par exemple deux dépendances différentes sous le *même* nom, parceque l'OS fournit une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
--
Michel TALON
Shmurtz <Gerald_Barre@beurk.org> wrote:
les options de dpkg sont pas mal non plus.:-)
Oui c'est de ça que je parlais en fait plutôt que de apt lui même.
En soi apt est neutre par rapport au système de paquetage, et il y a même
une distribution BSD (dflybsd) qui envisage de l'utiliser. Le problème n'est
pas là, le problème est comment faire coexister plusieurs dépendances
contradictoires, de façon que le problème de "stabilité" au sens de Debian
(c'est à dire la cohérence entre les paquets) ne se pose pas. Pour résoudre ce
problème il faut des techniques allant trés au delà du système de paquetage,
et même éventuellement des aides de l'OS (c'est aussi ce qui est envisagé
pour dflybsd - autrement dit que deux programmes différents voient par exemple
deux dépendances différentes sous le *même* nom, parceque l'OS fournit
une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
Oui c'est de ça que je parlais en fait plutôt que de apt lui même. En soi apt est neutre par rapport au système de paquetage, et il y a même une distribution BSD (dflybsd) qui envisage de l'utiliser. Le problème n'est pas là, le problème est comment faire coexister plusieurs dépendances contradictoires, de façon que le problème de "stabilité" au sens de Debian (c'est à dire la cohérence entre les paquets) ne se pose pas. Pour résoudre ce problème il faut des techniques allant trés au delà du système de paquetage, et même éventuellement des aides de l'OS (c'est aussi ce qui est envisagé pour dflybsd - autrement dit que deux programmes différents voient par exemple deux dépendances différentes sous le *même* nom, parceque l'OS fournit une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
--
Michel TALON
Irvin Probst
On 2004-07-19, Michel Talon wrote:
(c'est aussi ce qui est envisagé pour dflybsd - autrement dit que deux programmes différents voient par exemple deux dépendances différentes sous le *même* nom, parceque l'OS fournit une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
Ça a l'air interessant, ça sert à quoi ?
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
On 2004-07-19, Michel Talon <talon@lpthe.jussieu.fr> wrote:
(c'est aussi ce qui est envisagé
pour dflybsd - autrement dit que deux programmes différents voient par exemple
deux dépendances différentes sous le *même* nom, parceque l'OS fournit
une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
Ça a l'air interessant, ça sert à quoi ?
--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.
(c'est aussi ce qui est envisagé pour dflybsd - autrement dit que deux programmes différents voient par exemple deux dépendances différentes sous le *même* nom, parceque l'OS fournit une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
Ça a l'air interessant, ça sert à quoi ?
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
talon
Irvin Probst wrote:
On 2004-07-19, Michel Talon wrote:
(c'est aussi ce qui est envisagé pour dflybsd - autrement dit que deux programmes différents voient par exemple deux dépendances différentes sous le *même* nom, parceque l'OS fournit une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
Ça a l'air interessant, ça sert à quoi ?
Par exemple tu as des applications qui nécessitent perl5 version x.y et d'autres qui nécessitent perl5 version u.v. Ce n'est pas un exemple académique, ça existe. Résultat ces deux applications sont incompatibles. Sauf si l'une voit un /usr/bin/perl différent de l'autre, et si chaque /usr/bin/perl voit ses propres librairies. Or l'OS peut trés bien fournir une résolution différente de /usr/bin/perl dans la couche vfs selon le processus qui fait l'appel système. C'est ce genre de chose qui est envisagé dans dflybsd. Pour le moment il y a un mécanisme plus simple, et tiré de DomainOS, qui consiste à faire des liens symboliques à variantes. C'est à dire que selon la manière dont est positionnée une variable d'environnement, un lien symbolique est interprété de façon différente. Il suffit alors que /usr/bin/perl soit un lien symbolique vers *plusieurs* /usr/bin/perlvx.y l'interprétation dépendant du programme appelant. Evidemment ceci est à fortiori utilisable pour les librairies partagées qui se trouveraient être incompatibles.
Si tu veux voir ceci en oeuvre tu peux toujours essayer dragonflybsd il vient de sortir en version 1.0. Il y a aussi d'autres innovations, tels que le "checkpointing" de programme, c'est à dire la possibilité d'envoyer Ctrl+E à un programme, ce qui l'arrête et prend copie de tout son état, y compris les fichiers ouverts et permet de le relancer ultérieurement. Il y a aussi des tas d'autres innovations et il y en aura certainement beaucoup d'autres dans l'année à venir. Ce qui est fabuleux c'est quand tu vois que de telles choses sont faites par des développeurs de 17 ans et 20 ans! Ca donne un sacré coup au système scolaire usuel.
--
Michel TALON
Irvin Probst <irvin@trinity.irvinig.org> wrote:
On 2004-07-19, Michel Talon <talon@lpthe.jussieu.fr> wrote:
(c'est aussi ce qui est envisagé
pour dflybsd - autrement dit que deux programmes différents voient par exemple
deux dépendances différentes sous le *même* nom, parceque l'OS fournit
une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
Ça a l'air interessant, ça sert à quoi ?
Par exemple tu as des applications qui nécessitent perl5 version x.y et
d'autres qui nécessitent perl5 version u.v. Ce n'est pas un exemple
académique, ça existe. Résultat ces deux applications sont incompatibles.
Sauf si l'une voit un /usr/bin/perl différent de l'autre, et si chaque
/usr/bin/perl voit ses propres librairies. Or l'OS peut trés bien fournir
une résolution différente de /usr/bin/perl dans la couche vfs selon
le processus qui fait l'appel système. C'est ce genre de chose qui est
envisagé dans dflybsd. Pour le moment il y a un mécanisme plus simple,
et tiré de DomainOS, qui consiste à faire des liens symboliques à variantes.
C'est à dire que selon la manière dont est positionnée une variable
d'environnement, un lien symbolique est interprété de façon différente.
Il suffit alors que /usr/bin/perl soit un lien symbolique vers *plusieurs*
/usr/bin/perlvx.y l'interprétation dépendant du programme appelant.
Evidemment ceci est à fortiori utilisable pour les librairies partagées qui
se trouveraient être incompatibles.
Si tu veux voir ceci en oeuvre tu peux toujours essayer dragonflybsd
il vient de sortir en version 1.0. Il y a aussi d'autres innovations, tels que
le "checkpointing" de programme, c'est à dire la possibilité d'envoyer
Ctrl+E à un programme, ce qui l'arrête et prend copie de tout son état, y
compris les fichiers ouverts et permet de le relancer ultérieurement.
Il y a aussi des tas d'autres innovations et il y en aura certainement
beaucoup d'autres dans l'année à venir. Ce qui est fabuleux c'est quand tu
vois que de telles choses sont faites par des développeurs de 17 ans et 20 ans!
Ca donne un sacré coup au système scolaire usuel.
(c'est aussi ce qui est envisagé pour dflybsd - autrement dit que deux programmes différents voient par exemple deux dépendances différentes sous le *même* nom, parceque l'OS fournit une vision spécifique à chacun de ce qu'il y a par exemple dans /usr/lib).
Ça a l'air interessant, ça sert à quoi ?
Par exemple tu as des applications qui nécessitent perl5 version x.y et d'autres qui nécessitent perl5 version u.v. Ce n'est pas un exemple académique, ça existe. Résultat ces deux applications sont incompatibles. Sauf si l'une voit un /usr/bin/perl différent de l'autre, et si chaque /usr/bin/perl voit ses propres librairies. Or l'OS peut trés bien fournir une résolution différente de /usr/bin/perl dans la couche vfs selon le processus qui fait l'appel système. C'est ce genre de chose qui est envisagé dans dflybsd. Pour le moment il y a un mécanisme plus simple, et tiré de DomainOS, qui consiste à faire des liens symboliques à variantes. C'est à dire que selon la manière dont est positionnée une variable d'environnement, un lien symbolique est interprété de façon différente. Il suffit alors que /usr/bin/perl soit un lien symbolique vers *plusieurs* /usr/bin/perlvx.y l'interprétation dépendant du programme appelant. Evidemment ceci est à fortiori utilisable pour les librairies partagées qui se trouveraient être incompatibles.
Si tu veux voir ceci en oeuvre tu peux toujours essayer dragonflybsd il vient de sortir en version 1.0. Il y a aussi d'autres innovations, tels que le "checkpointing" de programme, c'est à dire la possibilité d'envoyer Ctrl+E à un programme, ce qui l'arrête et prend copie de tout son état, y compris les fichiers ouverts et permet de le relancer ultérieurement. Il y a aussi des tas d'autres innovations et il y en aura certainement beaucoup d'autres dans l'année à venir. Ce qui est fabuleux c'est quand tu vois que de telles choses sont faites par des développeurs de 17 ans et 20 ans! Ca donne un sacré coup au système scolaire usuel.
