Bonjour,
Je viens ici pour savoir quelle distribution BSD installée sur mon PC
(carte-mère récente avec processeur "dual-core" 4GO de RAM, carte-son M-
Audio Delta44) que j'utiliserai en station de travail et surtout via la
carte-son pour le décodage de signaux radioamateurs numériques (Fldigi
par exemple). Je suis sous Linux depuis de nombreuses années et la
curiosité me pousse à aller vers d'autres pâturages (L'herbe y est
toujours plus verte, ;-) )
D'avance, je vous remercie de vos réponses. Bon week-end!
Jean-Luc/F5JFA :-)
C'est ce que je disais. Je défends l'opinion que seul un système de paquets binaires peut fonctionner de manière fiable, ainsi qu'il est attesté par OpenBSD ou Debian, tandis qu'un système basé sur la compilation des sources vire inéluctablement au bordel généralisé.
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et le ./configure est allé chercher la lib Samba pour se lier dessus. Samba avait été installé pour un test, puis supprimé. Et mplayer est devenu cassé. Et ça, c'est le problème avec les distribs basées sur des sources, j'imagine que FreeBSD à le même souci.
Il y a en fait deux moyens de résoudre ce problème. Le premier consiste à lancer un ./configure avec des myriades d'options (--disable-smb je suppose dans mon cas) et le paquet se comporte _correctement_ comme attendu, soit on se débrouille pour tout piocher au runtime. Comment? Je ne sais pas vraiment, peut-être des systèmes de plugins.
Le second, c'est la distribution binaire, mais ce n'est pas la panacée. Debian découpe netcat en trois paquets distincts, c'est pas tellement plus malin.
On pourrait aussi imaginer que chaque paquet binaire embarque la totalité de ses libs, et détecte les libs déjà présentes au lancement pour les utiliser au cas où. En cas de mises à jour système qui casse le fonctionnement du programme, on a le fallback vers les libs associées au paquet [Avec un Warning éventuel]. On est sûr que le programme fonctionne, on mutualise les libs existantes, on suit les pbs de sécurité corrigés. Ceci dit, chaque paquet risque d'être énorme, mais puisque chacun dispose d'internet illimité et des disques de même propriété, cela reste une idée intéressante. -- Kevin
Le 12-02-2011, Michel Talon <talon@lpthe.jussieu.fr> a écrit :
C'est ce que je disais. Je défends l'opinion que seul un système de
paquets binaires peut fonctionner de manière fiable, ainsi qu'il est
attesté par OpenBSD ou Debian, tandis qu'un système basé sur
la compilation des sources vire inéluctablement au bordel généralisé.
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et
le ./configure est allé chercher la lib Samba pour se lier dessus.
Samba avait été installé pour un test, puis supprimé.
Et mplayer est devenu cassé. Et ça, c'est le problème avec les distribs
basées sur des sources, j'imagine que FreeBSD à le même souci.
Il y a en fait deux moyens de résoudre ce problème. Le premier
consiste à lancer un ./configure avec des myriades d'options
(--disable-smb je suppose dans mon cas) et le paquet se comporte
_correctement_ comme attendu, soit on se débrouille pour tout piocher
au runtime. Comment? Je ne sais pas vraiment, peut-être des systèmes
de plugins.
Le second, c'est la distribution binaire, mais ce n'est
pas la panacée. Debian découpe netcat en trois paquets distincts,
c'est pas tellement plus malin.
On pourrait aussi imaginer que chaque paquet binaire embarque la
totalité de ses libs, et détecte les libs déjà présentes au lancement
pour les utiliser au cas où. En cas de mises à jour système qui casse
le fonctionnement du programme, on a le fallback vers les libs
associées au paquet [Avec un Warning éventuel]. On est sûr que le
programme fonctionne, on mutualise les libs existantes, on suit
les pbs de sécurité corrigés. Ceci dit, chaque paquet risque d'être
énorme, mais puisque chacun dispose d'internet illimité et des
disques de même propriété, cela reste une idée intéressante.
--
Kevin
C'est ce que je disais. Je défends l'opinion que seul un système de paquets binaires peut fonctionner de manière fiable, ainsi qu'il est attesté par OpenBSD ou Debian, tandis qu'un système basé sur la compilation des sources vire inéluctablement au bordel généralisé.
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et le ./configure est allé chercher la lib Samba pour se lier dessus. Samba avait été installé pour un test, puis supprimé. Et mplayer est devenu cassé. Et ça, c'est le problème avec les distribs basées sur des sources, j'imagine que FreeBSD à le même souci.
Il y a en fait deux moyens de résoudre ce problème. Le premier consiste à lancer un ./configure avec des myriades d'options (--disable-smb je suppose dans mon cas) et le paquet se comporte _correctement_ comme attendu, soit on se débrouille pour tout piocher au runtime. Comment? Je ne sais pas vraiment, peut-être des systèmes de plugins.
Le second, c'est la distribution binaire, mais ce n'est pas la panacée. Debian découpe netcat en trois paquets distincts, c'est pas tellement plus malin.
On pourrait aussi imaginer que chaque paquet binaire embarque la totalité de ses libs, et détecte les libs déjà présentes au lancement pour les utiliser au cas où. En cas de mises à jour système qui casse le fonctionnement du programme, on a le fallback vers les libs associées au paquet [Avec un Warning éventuel]. On est sûr que le programme fonctionne, on mutualise les libs existantes, on suit les pbs de sécurité corrigés. Ceci dit, chaque paquet risque d'être énorme, mais puisque chacun dispose d'internet illimité et des disques de même propriété, cela reste une idée intéressante. -- Kevin
espie
In article , Stephane Catteau wrote:
Michel Talon n'était pas loin de dire :
Marc Espie wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ton "apparemment" est extremement faux.
In article <mn.7abe7db2113d08d9.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
Michel Talon n'était pas loin de dire :
Marc Espie <espie@lain.home> wrote:
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer
plusieurs packages avec une seule compil' et d'avoir des dependances runtime
qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD
ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A
part les mises à jours de sécurité, je n'ai pas du mettre à jour ma
passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a
fallut une semaine et une machine relais, et apparament ça ne s'est pas
arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Evidemment, c'est un peu plus de boulot, mais le fait de pouvoir generer plusieurs packages avec une seule compil' et d'avoir des dependances runtime qui dependent du package simplifient enormement les choses.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ton "apparemment" est extremement faux.
Miod Vallat
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une attaque personnelle contre ta paroisse.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD
ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A
part les mises à jours de sécurité, je n'ai pas du mettre à jour ma
passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a
fallut une semaine et une machine relais, et apparament ça ne s'est pas
arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une
attaque personnelle contre ta paroisse.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une attaque personnelle contre ta paroisse.
espie
In article <ijejkm$116u$, Miod Vallat wrote:
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une attaque personnelle contre ta paroisse.
Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit.
In article <ijejkm$116u$1@saria.nerim.net>,
Miod Vallat <miod@online.fr> wrote:
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD
ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A
part les mises à jours de sécurité, je n'ai pas du mettre à jour ma
passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a
fallut une semaine et une machine relais, et apparament ça ne s'est pas
arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une
attaque personnelle contre ta paroisse.
Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit.
Franchement, je crois que la plupart des mainteneurs de ports de FreeBSD ne sortent pas de Normale Sup.
Par contre les utilisateurs doivent en sortir, ce qui est absurde. A part les mises à jours de sécurité, je n'ai pas du mettre à jour ma passerelle depuis trois ans. La dernière fois que je l'ai fait il m'a fallut une semaine et une machine relais, et apparament ça ne s'est pas arrangé depuis :/
Si c'etait il y a trois ans, les choses ont enormement evolue depuis.
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une attaque personnelle contre ta paroisse.
Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit.
Miod Vallat
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une attaque personnelle contre ta paroisse.
Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit.
Une camomille, et au lit !
Si tu veux il me reste de la sauge et de la verveine, à la place de la camomille.
Ne t'énerve pas, il est écrit «FreeBSD» plus haut, ce n'est pas une
attaque personnelle contre ta paroisse.
Ah oui, tiens. Autant pour moi. Je retire ce que j'ai dit.
Une camomille, et au lit !
Si tu veux il me reste de la sauge et de la verveine, à la place de la
camomille.
Si tu veux il me reste de la sauge et de la verveine, à la place de la camomille.
Non, c'est bon, j'ai de la mirabelle.
Je parlais d'infusions, pas de tord-boyaux !
Fu2 buvette.
Antoine Leca
Kevin Denis écrivit :
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et le ./configure est allé chercher la lib Samba pour se lier dessus. Samba avait été installé pour un test, puis supprimé. Et mplayer est devenu cassé.
Un grand classique.
Et ça, c'est le problème avec les distribs basées sur des sources,
Pas vraiment. On a exactement le même problème sous Windows, qui n'est pas réputé pour être une distribution basée sur des sources :-) Les programmes (binaires) d'installation tentent de deviner la configuration de la machine cible, se trompent et installent les «mauvaises» DLLs ; ou, plus souvent, à la désinstallation, suppriment indument une DLL qui sert encore à autre chose (le fameux DLL hell). Dans ton cas ci-dessus, tu as le choix entre les deux erreurs (qui renvoient la « faute » sur chacun des deux paquetages ; tu as choisi mplayer comme présumé coupable, mais samba n'est que présumé innocent)
On a l'impression que c'est lié aux distribs basées sur des sources, parce qu'une distribution à partir des sources donne la possibilité d'intervenir facilement (--disable-smb, si ça marche pas --without-samba, etc.) pour essayer de résoudre le problème, magie de l'open source ; et comme nous y arrivons souvent, nous sommes amené à penser que ce sont ces i***s de mainteneurs de paquetages qui ne sont pas capables de prendre en compte correctement etc., couplet connu. En fait, c'est seulement le fait que l'accès aux sources permet plus facilement d'intervenir localement (à comparer aux logiciels fermés où il faut ouvrir un ticket, obtenir un fix etc.) qui donne donc une bien plus grande flexibilité.
Le vrai souci (ÀMHA), c'est que le programmeur (celui qui écrit le soft, mais aussi celui qui écrit le configure.ac) doivent théoriquement prévoir tous les cas possibles, et bien entendu il y a de la perte au feu. À un extrême on a les paquetages binaires à la Slackware qui éliminent une bonne partie de l'incertitude, mais bien sûr c'est au prix d'une rigidité souvent insupportable ; au fur et à mesure on a donc rajouté de « l'intelligence » aux paquetages, que ce soit la gestion des dépendances ou recourir à l'utilisation systématique de ./configure sur la machine cible ; ton idée d'embarquer la totalité des libs est une autre voie (qui est souvent celle des produits basés Windows). On remplace un travail humain (qui est celui de peaufiner à la main la configuration de son système) par des automatismes. Ce faisant, on rajoute du code, « donc » des bogues. Autre souci, les problèmes d'intégration sont très coûteux en temps de test, en particulier parce que les combinatoires explosent très vite.
Je crois que l'approche de Marc, binaires avec saveurs, que l'on peut aussi qualifier de modèle de la grande distribution (un petit choix de produits comparables, plus faciles à consommer directement), équilibrée mais restant pragmatique, est celle qui a le plus de chances de s'imposer sur le long terme ; mais cela risque d'être long. Et l'actuel succès de la grande distribution pour le commerce de détail ne signifie pas que le hard discount (les paquetages binaires stricts) ou l'épicerie (à partir des sources), qui est aussi le système promu par le « i-commerce », soient finis.
Antoine
Kevin Denis écrivit :
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et
le ./configure est allé chercher la lib Samba pour se lier dessus.
Samba avait été installé pour un test, puis supprimé.
Et mplayer est devenu cassé.
Un grand classique.
Et ça, c'est le problème avec les distribs basées sur des sources,
Pas vraiment. On a exactement le même problème sous Windows, qui n'est
pas réputé pour être une distribution basée sur des sources :-)
Les programmes (binaires) d'installation tentent de deviner la
configuration de la machine cible, se trompent et installent les
«mauvaises» DLLs ; ou, plus souvent, à la désinstallation, suppriment
indument une DLL qui sert encore à autre chose (le fameux DLL hell).
Dans ton cas ci-dessus, tu as le choix entre les deux erreurs (qui
renvoient la « faute » sur chacun des deux paquetages ; tu as choisi
mplayer comme présumé coupable, mais samba n'est que présumé innocent)
On a l'impression que c'est lié aux distribs basées sur des sources,
parce qu'une distribution à partir des sources donne la possibilité
d'intervenir facilement (--disable-smb, si ça marche pas
--without-samba, etc.) pour essayer de résoudre le problème, magie de
l'open source ; et comme nous y arrivons souvent, nous sommes amené à
penser que ce sont ces i***s de mainteneurs de paquetages qui ne sont
pas capables de prendre en compte correctement etc., couplet connu.
En fait, c'est seulement le fait que l'accès aux sources permet plus
facilement d'intervenir localement (à comparer aux logiciels fermés où
il faut ouvrir un ticket, obtenir un fix etc.) qui donne donc une bien
plus grande flexibilité.
Le vrai souci (ÀMHA), c'est que le programmeur (celui qui écrit le soft,
mais aussi celui qui écrit le configure.ac) doivent théoriquement
prévoir tous les cas possibles, et bien entendu il y a de la perte au
feu. À un extrême on a les paquetages binaires à la Slackware qui
éliminent une bonne partie de l'incertitude, mais bien sûr c'est au prix
d'une rigidité souvent insupportable ; au fur et à mesure on a donc
rajouté de « l'intelligence » aux paquetages, que ce soit la gestion des
dépendances ou recourir à l'utilisation systématique de ./configure sur
la machine cible ; ton idée d'embarquer la totalité des libs est une
autre voie (qui est souvent celle des produits basés Windows). On
remplace un travail humain (qui est celui de peaufiner à la main la
configuration de son système) par des automatismes. Ce faisant, on
rajoute du code, « donc » des bogues. Autre souci, les problèmes
d'intégration sont très coûteux en temps de test, en particulier parce
que les combinatoires explosent très vite.
Je crois que l'approche de Marc, binaires avec saveurs, que l'on peut
aussi qualifier de modèle de la grande distribution (un petit choix de
produits comparables, plus faciles à consommer directement), équilibrée
mais restant pragmatique, est celle qui a le plus de chances de
s'imposer sur le long terme ; mais cela risque d'être long.
Et l'actuel succès de la grande distribution pour le commerce de détail
ne signifie pas que le hard discount (les paquetages binaires stricts)
ou l'épicerie (à partir des sources), qui est aussi le système promu par
le « i-commerce », soient finis.
Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et le ./configure est allé chercher la lib Samba pour se lier dessus. Samba avait été installé pour un test, puis supprimé. Et mplayer est devenu cassé.
Un grand classique.
Et ça, c'est le problème avec les distribs basées sur des sources,
Pas vraiment. On a exactement le même problème sous Windows, qui n'est pas réputé pour être une distribution basée sur des sources :-) Les programmes (binaires) d'installation tentent de deviner la configuration de la machine cible, se trompent et installent les «mauvaises» DLLs ; ou, plus souvent, à la désinstallation, suppriment indument une DLL qui sert encore à autre chose (le fameux DLL hell). Dans ton cas ci-dessus, tu as le choix entre les deux erreurs (qui renvoient la « faute » sur chacun des deux paquetages ; tu as choisi mplayer comme présumé coupable, mais samba n'est que présumé innocent)
On a l'impression que c'est lié aux distribs basées sur des sources, parce qu'une distribution à partir des sources donne la possibilité d'intervenir facilement (--disable-smb, si ça marche pas --without-samba, etc.) pour essayer de résoudre le problème, magie de l'open source ; et comme nous y arrivons souvent, nous sommes amené à penser que ce sont ces i***s de mainteneurs de paquetages qui ne sont pas capables de prendre en compte correctement etc., couplet connu. En fait, c'est seulement le fait que l'accès aux sources permet plus facilement d'intervenir localement (à comparer aux logiciels fermés où il faut ouvrir un ticket, obtenir un fix etc.) qui donne donc une bien plus grande flexibilité.
Le vrai souci (ÀMHA), c'est que le programmeur (celui qui écrit le soft, mais aussi celui qui écrit le configure.ac) doivent théoriquement prévoir tous les cas possibles, et bien entendu il y a de la perte au feu. À un extrême on a les paquetages binaires à la Slackware qui éliminent une bonne partie de l'incertitude, mais bien sûr c'est au prix d'une rigidité souvent insupportable ; au fur et à mesure on a donc rajouté de « l'intelligence » aux paquetages, que ce soit la gestion des dépendances ou recourir à l'utilisation systématique de ./configure sur la machine cible ; ton idée d'embarquer la totalité des libs est une autre voie (qui est souvent celle des produits basés Windows). On remplace un travail humain (qui est celui de peaufiner à la main la configuration de son système) par des automatismes. Ce faisant, on rajoute du code, « donc » des bogues. Autre souci, les problèmes d'intégration sont très coûteux en temps de test, en particulier parce que les combinatoires explosent très vite.
Je crois que l'approche de Marc, binaires avec saveurs, que l'on peut aussi qualifier de modèle de la grande distribution (un petit choix de produits comparables, plus faciles à consommer directement), équilibrée mais restant pragmatique, est celle qui a le plus de chances de s'imposer sur le long terme ; mais cela risque d'être long. Et l'actuel succès de la grande distribution pour le commerce de détail ne signifie pas que le hard discount (les paquetages binaires stricts) ou l'épicerie (à partir des sources), qui est aussi le système promu par le « i-commerce », soient finis.
Antoine
talon
Antoine Leca wrote:
Kevin Denis écrivit : > Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et > le ./configure est allé chercher la lib Samba pour se lier dessus. > Samba avait été installé pour un test, puis supprimé. > Et mplayer est devenu cassé.
Un grand classique.
En effet, c'est pourquoi certains utilisent des arbres des ports chrootés pour construire les paquets dans un environnement propre, un à un. Je crois que les paquets de FreeBSD sont construits comme ça, encore ne faut il pas que le mainteneur du port ajoute inconsidérément des dépendances.
En fait, c'est seulement le fait que l'accès aux sources permet plus facilement d'intervenir localement (à comparer aux logiciels fermés où il faut ouvrir un ticket, obtenir un fix etc.) qui donne donc une bien plus grande flexibilité.
....
rajoute du code, « donc » des bogues. Autre souci, les problèmes d'intégration sont très coûteux en temps de test, en particulier parce que les combinatoires explosent très vite.
Ce sont bien ces deux facteurs, grande facilité à modifier les options et explosion combinatoire qui en résulte, qui font qu'une distribution basée sur les sources vire rapidement au bordel généralisé, tandis qu'une distriution binaire reste d'une complexité abordable.
Je crois que l'approche de Marc, binaires avec saveurs, que l'on peut aussi qualifier de modèle de la grande distribution (un petit choix de produits comparables, plus faciles à consommer directement), équilibrée mais restant pragmatique, est celle qui a le plus de chances de s'imposer sur le long terme ; mais cela risque d'être long.
C'est une approche qui est utilisée pragmatiquement un peu partout, par exemple dans FreeBSD tu as vim-lite qui n'a pas de dépendance sur X11 et vim qui a les fonctionnalités X11. Mais ensuite tu as des dépendances de vim sur divers languages (perl, python, ruby, etc.) qu'on te fourre en travers de la gorge sans te demander ton avis. Ce n'est pas parceque tu vas éditer du python avec vim que tu as besoin en quoi que ce soit de la dépendance python qui sert à faire tourner du code python dans vim.
Bref le problème, à mon avis, c'est surtout les mainteneurs. Il suffit de voir dans les mailing lists à quel point ils sont arc-boutés sur leurs habitudes, refusant toute discussion sur d'autres pratiques, défendant jalousement chacun leur pré carré. De toute évidence pour beaucoup ils ont conquis de haute lutte leur titre de "développeur machin" qui est la plus haute distinction de leur vie, et ne sont pas prêts à la moindre concession. L'exemple le plus récent que j'ai, c'est le fil de discussion sur la debian-kfreebsd dans la mailing list FreeBSD. Les posteurs qui se proposaient d'en discuter ont été sèchement renvoyés dans leurs buts avec pour argument: "ici on discute de FreeBSD, ceux qui veulent discuter de Debian savent où il faut aller". Or justement Debian propose un modèle débianisé pour FreeBSD qui est peut être l'avenir de FreeBSD, donc c'est un sujet *très* important. Pour moi, FreeBSD c'est d'abord le travail des développeurs du noyau, qui sont certainement compétents, la question des ports n'est que périphérique, et on pourrait très bien changer complètement de système s'il est avéré (c'est mon avis) que le système actuel s'effondre.
--
Michel TALON
Antoine Leca <root@localhost.invalid> wrote:
Kevin Denis écrivit :
> Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et
> le ./configure est allé chercher la lib Samba pour se lier dessus.
> Samba avait été installé pour un test, puis supprimé.
> Et mplayer est devenu cassé.
Un grand classique.
En effet, c'est pourquoi certains utilisent des arbres des ports
chrootés pour construire les paquets dans un environnement propre,
un à un. Je crois que les paquets de FreeBSD sont construits comme
ça, encore ne faut il pas que le mainteneur du port ajoute
inconsidérément des dépendances.
En fait, c'est seulement le fait que l'accès aux sources permet plus
facilement d'intervenir localement (à comparer aux logiciels fermés où
il faut ouvrir un ticket, obtenir un fix etc.) qui donne donc une bien
plus grande flexibilité.
....
rajoute du code, « donc » des bogues. Autre souci, les problèmes
d'intégration sont très coûteux en temps de test, en particulier parce
que les combinatoires explosent très vite.
Ce sont bien ces deux facteurs, grande facilité à modifier les options
et explosion combinatoire qui en résulte, qui font qu'une distribution
basée sur les sources vire rapidement au bordel généralisé, tandis
qu'une distriution binaire reste d'une complexité abordable.
Je crois que l'approche de Marc, binaires avec saveurs, que l'on peut
aussi qualifier de modèle de la grande distribution (un petit choix de
produits comparables, plus faciles à consommer directement), équilibrée
mais restant pragmatique, est celle qui a le plus de chances de
s'imposer sur le long terme ; mais cela risque d'être long.
C'est une approche qui est utilisée pragmatiquement un peu partout, par
exemple dans FreeBSD tu as vim-lite qui n'a pas de dépendance sur X11 et
vim qui a les fonctionnalités X11. Mais ensuite tu as des dépendances de
vim sur divers languages (perl, python, ruby, etc.) qu'on te fourre en
travers de la gorge sans te demander ton avis. Ce n'est pas parceque tu
vas éditer du python avec vim que tu as besoin en quoi que ce soit de la
dépendance python qui sert à faire tourner du code python dans vim.
Bref le problème, à mon avis, c'est surtout les mainteneurs. Il suffit
de voir dans les mailing lists à quel point ils sont arc-boutés sur
leurs habitudes, refusant toute discussion sur d'autres pratiques,
défendant jalousement chacun leur pré carré. De toute évidence pour
beaucoup ils ont conquis de haute lutte leur titre de "développeur
machin" qui est la plus haute distinction de leur vie, et ne sont pas
prêts à la moindre concession. L'exemple le plus récent que j'ai, c'est
le fil de discussion sur la debian-kfreebsd dans la mailing list
FreeBSD. Les posteurs qui se proposaient d'en discuter ont été sèchement
renvoyés dans leurs buts avec pour argument: "ici on discute de FreeBSD,
ceux qui veulent discuter de Debian savent où il faut aller". Or
justement Debian propose un modèle débianisé pour FreeBSD qui est peut
être l'avenir de FreeBSD, donc c'est un sujet *très* important. Pour
moi, FreeBSD c'est d'abord le travail des développeurs du noyau, qui
sont certainement compétents, la question des ports n'est que
périphérique, et on pourrait très bien changer complètement de système
s'il est avéré (c'est mon avis) que le système actuel s'effondre.
Kevin Denis écrivit : > Pas sur. J'ai eu un exemple récent. Recompilation de mplayer. Et > le ./configure est allé chercher la lib Samba pour se lier dessus. > Samba avait été installé pour un test, puis supprimé. > Et mplayer est devenu cassé.
Un grand classique.
En effet, c'est pourquoi certains utilisent des arbres des ports chrootés pour construire les paquets dans un environnement propre, un à un. Je crois que les paquets de FreeBSD sont construits comme ça, encore ne faut il pas que le mainteneur du port ajoute inconsidérément des dépendances.
En fait, c'est seulement le fait que l'accès aux sources permet plus facilement d'intervenir localement (à comparer aux logiciels fermés où il faut ouvrir un ticket, obtenir un fix etc.) qui donne donc une bien plus grande flexibilité.
....
rajoute du code, « donc » des bogues. Autre souci, les problèmes d'intégration sont très coûteux en temps de test, en particulier parce que les combinatoires explosent très vite.
Ce sont bien ces deux facteurs, grande facilité à modifier les options et explosion combinatoire qui en résulte, qui font qu'une distribution basée sur les sources vire rapidement au bordel généralisé, tandis qu'une distriution binaire reste d'une complexité abordable.
Je crois que l'approche de Marc, binaires avec saveurs, que l'on peut aussi qualifier de modèle de la grande distribution (un petit choix de produits comparables, plus faciles à consommer directement), équilibrée mais restant pragmatique, est celle qui a le plus de chances de s'imposer sur le long terme ; mais cela risque d'être long.
C'est une approche qui est utilisée pragmatiquement un peu partout, par exemple dans FreeBSD tu as vim-lite qui n'a pas de dépendance sur X11 et vim qui a les fonctionnalités X11. Mais ensuite tu as des dépendances de vim sur divers languages (perl, python, ruby, etc.) qu'on te fourre en travers de la gorge sans te demander ton avis. Ce n'est pas parceque tu vas éditer du python avec vim que tu as besoin en quoi que ce soit de la dépendance python qui sert à faire tourner du code python dans vim.
Bref le problème, à mon avis, c'est surtout les mainteneurs. Il suffit de voir dans les mailing lists à quel point ils sont arc-boutés sur leurs habitudes, refusant toute discussion sur d'autres pratiques, défendant jalousement chacun leur pré carré. De toute évidence pour beaucoup ils ont conquis de haute lutte leur titre de "développeur machin" qui est la plus haute distinction de leur vie, et ne sont pas prêts à la moindre concession. L'exemple le plus récent que j'ai, c'est le fil de discussion sur la debian-kfreebsd dans la mailing list FreeBSD. Les posteurs qui se proposaient d'en discuter ont été sèchement renvoyés dans leurs buts avec pour argument: "ici on discute de FreeBSD, ceux qui veulent discuter de Debian savent où il faut aller". Or justement Debian propose un modèle débianisé pour FreeBSD qui est peut être l'avenir de FreeBSD, donc c'est un sujet *très* important. Pour moi, FreeBSD c'est d'abord le travail des développeurs du noyau, qui sont certainement compétents, la question des ports n'est que périphérique, et on pourrait très bien changer complètement de système s'il est avéré (c'est mon avis) que le système actuel s'effondre.
--
Michel TALON
Vivien MOREAU
On 2011-02-16, Michel Talon wrote:
Pour moi, FreeBSD c'est d'abord le travail des développeurs du noyau, qui sont certainement compétents, la question des ports n'est que périphérique, et on pourrait très bien changer complètement de système s'il est avéré (c'est mon avis) que le système actuel s'effondre.
Tu parles comme si FreeBSD, ce n'était qu'un noyau et des ports. Tu oublies que c'est aussi des outils systèmes fortement corrélés au noyau. Si jamais le système de base de FreeBSD ( hors ports, donc ) devient naze, la solution est de l'améliorer, pas de le remplacer par les outils GNU.
-- Message envoyé depuis mon iMug
On 2011-02-16, Michel Talon wrote:
Pour moi, FreeBSD c'est d'abord le travail des développeurs du
noyau, qui sont certainement compétents, la question des ports n'est
que périphérique, et on pourrait très bien changer complètement de
système s'il est avéré (c'est mon avis) que le système actuel
s'effondre.
Tu parles comme si FreeBSD, ce n'était qu'un noyau et des ports.
Tu oublies que c'est aussi des outils systèmes fortement corrélés
au noyau. Si jamais le système de base de FreeBSD ( hors ports,
donc ) devient naze, la solution est de l'améliorer, pas de le
remplacer par les outils GNU.
Pour moi, FreeBSD c'est d'abord le travail des développeurs du noyau, qui sont certainement compétents, la question des ports n'est que périphérique, et on pourrait très bien changer complètement de système s'il est avéré (c'est mon avis) que le système actuel s'effondre.
Tu parles comme si FreeBSD, ce n'était qu'un noyau et des ports. Tu oublies que c'est aussi des outils systèmes fortement corrélés au noyau. Si jamais le système de base de FreeBSD ( hors ports, donc ) devient naze, la solution est de l'améliorer, pas de le remplacer par les outils GNU.
