Pour precher pour ma paroisse, notre systeme de packages torsche maintenant celui de Net, et celui de Free (les 3/4 de la doc de Michel ne sont pas necessaires chez nous, par exemple, et ont a depuis plus d'un an des packages binaires qui fonctionnent `sans le moindre probleme' et un outil de mise-a-jour (pkg_add -u) qui va maintenant passer sa deuxieme release sans encombre.
Mon avis, que je sais que la plupart des utilisateurs de FreeBSD ne partagent pas, mais qui est plus proche du tien, est qu'un système de paquets ne peut fonctionner correctement qu'à partir de paquets binaires. C'est ce que fait Debian, et ça marche. J'en ai encore eu l'expérience récemment, il n'y a pas de doute que ça marche vite et bien.
Maintenant, il y a un problème avec ça, il y a des gens qui veulent recompiler leurs programmes, donc il faut que les deux s'intègrent bien. Et surtout le plus grave, il y a des paquets que tu ne peux pas fournir en binaire, ce qui pose un gros problème dans ma logique. Exemple le Java de sun avant l'existence du diablo-jdk. Or il est fort possible que ces programmes soient essentiels et que beaucoup d'autres dépendent d'eux, ici par exemple Tomcat, et tout ce qui va avec. Les gens de Debian ont une solution à ce problème, pour eux il n'y a de paquets que ce qui est suffisamment libre, et tout figure donc dans leurs "repositories", si bien que apt-get fonctionne au poil. Il y a une autre solution, je me suis laissé dire que c'est la votre (donc je colporte purement des ragots) qui consiste à avoir si peu de paquets que le problème ne se pose pas.
Ni l'une ni l'autre de ces solution ne me convient, je ne veux pas qu'on me fourgue un gcj poussif pour remplacer le jdk de Sun pour des raisons dont honnêtement je me tamponne complètement. Donc il faut malheureusement envisager un système où au moins une partie des paquets doivent être compilés à la maison, ce qui veut dire qu'ils risquent fort de ne pas compiler, ou de compiler et de ne pas marcher. Evidemment ça crée forcément la zone avec un outil d'upgrade comme "portupgrade" - ou tout autre plus récent et moins bien. Tu risques de te retrouver en plein milieu bloqué avec la moitié des ports upgradés et l'autre ancienne. J'ai beau tourner le problème dans tous les sens, je ne vois aucune manière que ça n'arrive pas sans utiliser purement des paquets binaires.
Voilà pourquoi je me contente d'upgrader ma machine quand il y a des releases, et purement avec des paquets binaires, si possible. Les outils qui existent pour faire ça sous FreeBSD soit ne marchent pas, soit sont d'une lenteur démoniaque. Je voudrais un outil qui regarde ce qu'il y a sur la machine, ce qu'il y a dans le dépôt FreeBSD, me propose d'upgrader ce qui est possible, de compiler ce qui ne l'est pas, de faire venir tout ce dont il y a besoin *avant de commencer quoi que ce soit*. Je ne veux pas que cette phase prenne 3 heures. Apt-get fait exactement ça en quelques secondes pour analyser la situation et quelques minutes pour télécharger les paquets. Ensuite je veux bien courir le risque de compiler quelques petits trucs aprés coup, ou faire l'opération lourde de compiler dans une "jail" , et d'installer tout le bazar. Ca doit prendre de l'ordre de 15 minutes, pas de l'ordre de plusieurs heures comme le fait portupgrade actuellement, parceque je veux être là quand ça se passe et pas trouver une mauvaise surprise au retour. Voilà exactement ce que j'ai envie d'écrire, et je suis persuadé que c'est un truc assez court à faire en python. L'exemple du programme que je viens de faire montre qu'il serait stupide de le faire en C on gagnerait des pouillèmes. Il montre aussi qu'on peut analyser de l'ordre de 600 ports en moins de deux minutes, et encore dans ce cas là avec un boulet au pied.
--
Michel TALON
Marc Espie <espie@lain.home> wrote:
Pour precher pour ma paroisse, notre systeme de packages torsche maintenant
celui de Net, et celui de Free (les 3/4 de la doc de Michel ne sont pas
necessaires chez nous, par exemple, et ont a depuis plus d'un an des
packages binaires qui fonctionnent `sans le moindre probleme' et un outil
de mise-a-jour (pkg_add -u) qui va maintenant passer sa deuxieme release
sans encombre.
Mon avis, que je sais que la plupart des utilisateurs de FreeBSD ne partagent
pas, mais qui est plus proche du tien, est qu'un système de paquets ne peut
fonctionner correctement qu'à partir de paquets binaires. C'est ce que fait
Debian, et ça marche. J'en ai encore eu l'expérience récemment, il n'y a pas
de doute que ça marche vite et bien.
Maintenant, il y a un problème avec ça, il y a des gens qui veulent recompiler
leurs programmes, donc il faut que les deux s'intègrent bien. Et surtout le
plus grave, il y a des paquets que tu ne peux pas fournir en binaire, ce qui
pose un gros problème dans ma logique. Exemple le Java de sun avant
l'existence du diablo-jdk. Or il est fort possible que ces programmes soient
essentiels et que beaucoup d'autres dépendent d'eux, ici par exemple Tomcat,
et tout ce qui va avec. Les gens de Debian ont une solution à ce problème,
pour eux il n'y a de paquets que ce qui est suffisamment libre, et tout figure
donc dans leurs "repositories", si bien que apt-get fonctionne au poil.
Il y a une autre solution, je me suis laissé dire que c'est la votre (donc je
colporte purement des ragots) qui consiste à avoir si peu de paquets que le
problème ne se pose pas.
Ni l'une ni l'autre de ces solution ne me convient, je ne veux pas qu'on me
fourgue un gcj poussif pour remplacer le jdk de Sun pour des raisons dont
honnêtement je me tamponne complètement. Donc il faut malheureusement
envisager un système où au moins une partie des paquets doivent être compilés
à la maison, ce qui veut dire qu'ils risquent fort de ne pas compiler, ou
de compiler et de ne pas marcher. Evidemment ça crée forcément la zone avec un
outil d'upgrade comme "portupgrade" - ou tout autre plus récent et moins bien.
Tu risques de te retrouver en plein milieu bloqué avec la moitié des ports
upgradés et l'autre ancienne. J'ai beau tourner le problème dans tous les
sens, je ne vois aucune manière que ça n'arrive pas sans utiliser purement des
paquets binaires.
Voilà pourquoi je me contente d'upgrader ma machine quand il y a des releases,
et purement avec des paquets binaires, si possible. Les outils qui existent
pour faire ça sous FreeBSD soit ne marchent pas, soit sont d'une lenteur
démoniaque. Je voudrais un outil qui regarde ce qu'il y a sur la machine, ce
qu'il y a dans le dépôt FreeBSD, me propose d'upgrader ce qui est possible, de
compiler ce qui ne l'est pas, de faire venir tout ce dont il y a besoin
*avant de commencer quoi que ce soit*. Je ne veux pas que cette phase prenne 3
heures. Apt-get fait exactement ça en quelques secondes pour analyser la
situation et quelques minutes pour télécharger les paquets. Ensuite je veux
bien courir le risque de compiler quelques petits trucs aprés coup, ou faire
l'opération lourde de compiler dans une "jail" , et d'installer tout le bazar.
Ca doit prendre de l'ordre de 15 minutes, pas de l'ordre de plusieurs heures
comme le fait portupgrade actuellement, parceque je veux être là quand ça se
passe et pas trouver une mauvaise surprise au retour. Voilà exactement ce que
j'ai envie d'écrire, et je suis persuadé que c'est un truc assez court à faire
en python. L'exemple du programme que je viens de faire montre qu'il serait
stupide de le faire en C on gagnerait des pouillèmes. Il montre aussi qu'on
peut analyser de l'ordre de 600 ports en moins de deux minutes, et encore dans
ce cas là avec un boulet au pied.
Pour precher pour ma paroisse, notre systeme de packages torsche maintenant celui de Net, et celui de Free (les 3/4 de la doc de Michel ne sont pas necessaires chez nous, par exemple, et ont a depuis plus d'un an des packages binaires qui fonctionnent `sans le moindre probleme' et un outil de mise-a-jour (pkg_add -u) qui va maintenant passer sa deuxieme release sans encombre.
Mon avis, que je sais que la plupart des utilisateurs de FreeBSD ne partagent pas, mais qui est plus proche du tien, est qu'un système de paquets ne peut fonctionner correctement qu'à partir de paquets binaires. C'est ce que fait Debian, et ça marche. J'en ai encore eu l'expérience récemment, il n'y a pas de doute que ça marche vite et bien.
Maintenant, il y a un problème avec ça, il y a des gens qui veulent recompiler leurs programmes, donc il faut que les deux s'intègrent bien. Et surtout le plus grave, il y a des paquets que tu ne peux pas fournir en binaire, ce qui pose un gros problème dans ma logique. Exemple le Java de sun avant l'existence du diablo-jdk. Or il est fort possible que ces programmes soient essentiels et que beaucoup d'autres dépendent d'eux, ici par exemple Tomcat, et tout ce qui va avec. Les gens de Debian ont une solution à ce problème, pour eux il n'y a de paquets que ce qui est suffisamment libre, et tout figure donc dans leurs "repositories", si bien que apt-get fonctionne au poil. Il y a une autre solution, je me suis laissé dire que c'est la votre (donc je colporte purement des ragots) qui consiste à avoir si peu de paquets que le problème ne se pose pas.
Ni l'une ni l'autre de ces solution ne me convient, je ne veux pas qu'on me fourgue un gcj poussif pour remplacer le jdk de Sun pour des raisons dont honnêtement je me tamponne complètement. Donc il faut malheureusement envisager un système où au moins une partie des paquets doivent être compilés à la maison, ce qui veut dire qu'ils risquent fort de ne pas compiler, ou de compiler et de ne pas marcher. Evidemment ça crée forcément la zone avec un outil d'upgrade comme "portupgrade" - ou tout autre plus récent et moins bien. Tu risques de te retrouver en plein milieu bloqué avec la moitié des ports upgradés et l'autre ancienne. J'ai beau tourner le problème dans tous les sens, je ne vois aucune manière que ça n'arrive pas sans utiliser purement des paquets binaires.
Voilà pourquoi je me contente d'upgrader ma machine quand il y a des releases, et purement avec des paquets binaires, si possible. Les outils qui existent pour faire ça sous FreeBSD soit ne marchent pas, soit sont d'une lenteur démoniaque. Je voudrais un outil qui regarde ce qu'il y a sur la machine, ce qu'il y a dans le dépôt FreeBSD, me propose d'upgrader ce qui est possible, de compiler ce qui ne l'est pas, de faire venir tout ce dont il y a besoin *avant de commencer quoi que ce soit*. Je ne veux pas que cette phase prenne 3 heures. Apt-get fait exactement ça en quelques secondes pour analyser la situation et quelques minutes pour télécharger les paquets. Ensuite je veux bien courir le risque de compiler quelques petits trucs aprés coup, ou faire l'opération lourde de compiler dans une "jail" , et d'installer tout le bazar. Ca doit prendre de l'ordre de 15 minutes, pas de l'ordre de plusieurs heures comme le fait portupgrade actuellement, parceque je veux être là quand ça se passe et pas trouver une mauvaise surprise au retour. Voilà exactement ce que j'ai envie d'écrire, et je suis persuadé que c'est un truc assez court à faire en python. L'exemple du programme que je viens de faire montre qu'il serait stupide de le faire en C on gagnerait des pouillèmes. Il montre aussi qu'on peut analyser de l'ordre de 600 ports en moins de deux minutes, et encore dans ce cas là avec un boulet au pied.
--
Michel TALON
talon
F. Senault wrote:
F. Senault wrote:
Incidemment, l'option -U est apparue dans les dernières versions, qui devrait rendre le processus encore beaucoup plus simple. Elle permet d'auto-upgrader des fichiers qui n'ont pas été modifiés par l'utilisateur, c'est-à-dire 99% du temps, tous les répertoires default, tous les scripts rc, les répertoires mtree, etc.
Et il a fallu combien d'*années* et de discussions à perte de vue pour introduire cette option si pratique et complètement évidente?
Un petit bout de temps, je ne dis pas le contraire. Un certain nombre de gens avaient visiblement un peu peur des effets de bord possibles.
A noter qu'à mon avis, il devrait y avoir un certain nombre de fichiers écrabouillés sans confirmations, et puis baste. Notamment tous les defaults, et tous les scripts rc.
Ca me paraît évident. Les "défaults" et les "rc" n'ont pas à être édités par l'utilisateur, et donc doivent être écrabouillés. Réciproquement, venir proposer d'installer printcap ou passwd c'est exposer les gens à perdre les imprimantes ou les utilisateurs. Donc c'est merdique, il faut être taré pour proposer un sytème comme ça. Certes il arrive qu'il faille rajouter un utilisateur "système" dans passwd, il ne m'échappe pas que ceci peut être réalisé trivialement sans proposer quoi que ce soit à l'utilisateur. Bref, pour faire court, mergemaster est une bouse.
Fred
--
Michel TALON
F. Senault <fred@lacave.net> wrote:
F. Senault <fred@lacave.net> wrote:
Incidemment, l'option -U est apparue dans les dernières versions, qui
devrait rendre le processus encore beaucoup plus simple. Elle permet
d'auto-upgrader des fichiers qui n'ont pas été modifiés par
l'utilisateur, c'est-à-dire 99% du temps, tous les répertoires default,
tous les scripts rc, les répertoires mtree, etc.
Et il a fallu combien d'*années* et de discussions à perte de vue pour
introduire cette option si pratique et complètement évidente?
Un petit bout de temps, je ne dis pas le contraire. Un certain nombre
de gens avaient visiblement un peu peur des effets de bord possibles.
A noter qu'à mon avis, il devrait y avoir un certain nombre de fichiers
écrabouillés sans confirmations, et puis baste. Notamment tous les
defaults, et tous les scripts rc.
Ca me paraît évident. Les "défaults" et les "rc" n'ont pas à être édités par
l'utilisateur, et donc doivent être écrabouillés. Réciproquement, venir
proposer d'installer printcap ou passwd c'est exposer les gens à perdre
les imprimantes ou les utilisateurs. Donc c'est merdique, il faut être taré
pour proposer un sytème comme ça. Certes il arrive qu'il faille rajouter un
utilisateur "système" dans passwd, il ne m'échappe pas que ceci peut
être réalisé trivialement sans proposer quoi que ce soit à l'utilisateur.
Bref, pour faire court, mergemaster est une bouse.
Incidemment, l'option -U est apparue dans les dernières versions, qui devrait rendre le processus encore beaucoup plus simple. Elle permet d'auto-upgrader des fichiers qui n'ont pas été modifiés par l'utilisateur, c'est-à-dire 99% du temps, tous les répertoires default, tous les scripts rc, les répertoires mtree, etc.
Et il a fallu combien d'*années* et de discussions à perte de vue pour introduire cette option si pratique et complètement évidente?
Un petit bout de temps, je ne dis pas le contraire. Un certain nombre de gens avaient visiblement un peu peur des effets de bord possibles.
A noter qu'à mon avis, il devrait y avoir un certain nombre de fichiers écrabouillés sans confirmations, et puis baste. Notamment tous les defaults, et tous les scripts rc.
Ca me paraît évident. Les "défaults" et les "rc" n'ont pas à être édités par l'utilisateur, et donc doivent être écrabouillés. Réciproquement, venir proposer d'installer printcap ou passwd c'est exposer les gens à perdre les imprimantes ou les utilisateurs. Donc c'est merdique, il faut être taré pour proposer un sytème comme ça. Certes il arrive qu'il faille rajouter un utilisateur "système" dans passwd, il ne m'échappe pas que ceci peut être réalisé trivialement sans proposer quoi que ce soit à l'utilisateur. Bref, pour faire court, mergemaster est une bouse.
Fred
--
Michel TALON
F. Senault
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Ciao,
Fred -- Do you ever get tired of the waiting ? Do you ever get tired of being in there ? Don't worry, nobody lives forever, Nobody lives forever (Pink Floyd, A New Machine, part I)
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est
plutôt fatiguant à lire, à la fin.
Ciao,
Fred
--
Do you ever get tired of the waiting ?
Do you ever get tired of being in there ?
Don't worry, nobody lives forever,
Nobody lives forever (Pink Floyd, A New Machine, part I)
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Ciao,
Fred -- Do you ever get tired of the waiting ? Do you ever get tired of being in there ? Don't worry, nobody lives forever, Nobody lives forever (Pink Floyd, A New Machine, part I)
Miod Vallat
Pour precher pour ma paroisse, notre systeme de packages torsche maintenant ^^^^^^^
Ça s'est vu.
Le reste du projet a suffisamment de chantiers en cours pour bien s'occuper pendant quelques annees...
s:annees:générations:
Pour precher pour ma paroisse, notre systeme de packages torsche maintenant
^^^^^^^
Ça s'est vu.
Le reste du projet a suffisamment de chantiers en cours pour bien s'occuper
pendant quelques annees...
Pour precher pour ma paroisse, notre systeme de packages torsche maintenant ^^^^^^^
Ça s'est vu.
Le reste du projet a suffisamment de chantiers en cours pour bien s'occuper pendant quelques annees...
s:annees:générations:
Miod Vallat
Je commençais en 1997 avec Linux, puis FreeBSD, OpenBSD et NetBSD, tout celà tout seul. Je n'aurai pas réussi à démarrer directement sous NetBSD. Pour celà, il fallait déjà une certaine expérience, surtout en 1997. Le succès de Linux à l'époque résidait en bonne partie dans les Howto.
Oui, mais c'est aussi une faiblesse : le niveau technique d'un howto à l'autre varie énormément, et certains sont faux... ou ne fonctionnent que par accident, sur une distribution donnée, etc.
Le problème derrière cette situation est que la coordination des howto ne s'occupe que du caractère logistique (diffusion, traduction, mise à jour des textes quand nécessaire), mais pas de la pertinence technique des textes.
Je commençais en 1997 avec Linux, puis FreeBSD, OpenBSD et NetBSD, tout celà
tout seul. Je n'aurai pas réussi à démarrer directement sous NetBSD. Pour
celà, il fallait déjà une certaine expérience, surtout en 1997. Le succès de
Linux à l'époque résidait en bonne partie dans les Howto.
Oui, mais c'est aussi une faiblesse : le niveau technique d'un howto à
l'autre varie énormément, et certains sont faux... ou ne fonctionnent
que par accident, sur une distribution donnée, etc.
Le problème derrière cette situation est que la coordination des howto
ne s'occupe que du caractère logistique (diffusion, traduction, mise à
jour des textes quand nécessaire), mais pas de la pertinence technique
des textes.
Je commençais en 1997 avec Linux, puis FreeBSD, OpenBSD et NetBSD, tout celà tout seul. Je n'aurai pas réussi à démarrer directement sous NetBSD. Pour celà, il fallait déjà une certaine expérience, surtout en 1997. Le succès de Linux à l'époque résidait en bonne partie dans les Howto.
Oui, mais c'est aussi une faiblesse : le niveau technique d'un howto à l'autre varie énormément, et certains sont faux... ou ne fonctionnent que par accident, sur une distribution donnée, etc.
Le problème derrière cette situation est que la coordination des howto ne s'occupe que du caractère logistique (diffusion, traduction, mise à jour des textes quand nécessaire), mais pas de la pertinence technique des textes.
talon
F. Senault wrote:
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Ciao,
Fred
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de choses du même genre que les institutions dérivent vers le déclin et que les nuls prennent le pouvoir partout. Mergemaster ne vaut rien, il a eu des années pour s'améliorer il est à peine un peu mieux. Les gens qui chantent les louanges de mergemaster sont les mêmes qui chanteront les louanges d'un autre bidule aussi minable qui lui succédera, qui sont les perpétuels béni oui-oui. Il y a heureusement chez FreeBSD des gens de trés grand talent comme phk, R. Watson ou PJ Dawidek, ce qui fait que c'est encore un système intéressant. Ces gens ne sont pas les derniers à casser du sucre sur le dos des choses qui sont rééllement en piteux état.
--
Michel TALON
F. Senault <fred@lacave.net> wrote:
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est
plutôt fatiguant à lire, à la fin.
Ciao,
Fred
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de
choses du même genre que les institutions dérivent vers le déclin et que les
nuls prennent le pouvoir partout. Mergemaster ne vaut rien, il a eu des années
pour s'améliorer il est à peine un peu mieux. Les gens qui chantent les
louanges de mergemaster sont les mêmes qui chanteront les louanges d'un autre
bidule aussi minable qui lui succédera, qui sont les perpétuels béni oui-oui.
Il y a heureusement chez FreeBSD des gens de trés grand talent comme phk, R.
Watson ou PJ Dawidek, ce qui fait que c'est encore un système intéressant. Ces
gens ne sont pas les derniers à casser du sucre sur le dos des choses qui sont
rééllement en piteux état.
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Ciao,
Fred
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de choses du même genre que les institutions dérivent vers le déclin et que les nuls prennent le pouvoir partout. Mergemaster ne vaut rien, il a eu des années pour s'améliorer il est à peine un peu mieux. Les gens qui chantent les louanges de mergemaster sont les mêmes qui chanteront les louanges d'un autre bidule aussi minable qui lui succédera, qui sont les perpétuels béni oui-oui. Il y a heureusement chez FreeBSD des gens de trés grand talent comme phk, R. Watson ou PJ Dawidek, ce qui fait que c'est encore un système intéressant. Ces gens ne sont pas les derniers à casser du sucre sur le dos des choses qui sont rééllement en piteux état.
--
Michel TALON
Quentin Garnier
(Désolé, je teste Thunderbird. Don't ask.)
[...]
Ah si: il faut lire cette saillie en sachant que la fondation NetBSD (TNF) viens de décider de clore le compte de la dizaine de developpeurs qui ont refusés de signer le developer agreement (un papier où on dit qu'on est gentil et qu'on va pas faire n'importe quoi). Charles, qui est là depuis une époque où ce genre de paperasse n'existait pas, n'a jamais voulu le signer. Je trouve pour ma part un peu regrettable qu'un papier à l'utilité douteuse nous mène à mettre dehors un important contributeur. Mais d'un autre coté, l'incident révèle aussi une certaine rigidité de la part de Charles: pourquoi refuser de signer ce truc, après tout?
C'est marrant que tu perçoives les choses comme ça. C'est lui-même qui a mis en place cette paperasserie justement, après avoir créé la fondation.
Aucun agreement n'a été perdu, c'est lui qui se les garde pour lui.
Je vois les choses différemment; Hannum s'est endormi pendant un moment sur la Fondation et ne s'est réveillé qu'une fois que Zoulas eut fini de terminer les paperasseries nécessaire à la continuité d'une telle entité. Depuis il l'a mauvaise.
Il faut noter que l'agreement a une importance précise dans la mesure où TNF est titulaire du copyright d'une grande partie du code. D'accord, ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à TNF pour du code d'origine pas forcément connue (du point de vue de TNF, j'entends). Ce serait d'ailleurs un cas d'école assez marrant si un quidam (ne me faites pas dire ce que je n'ai pas dit, je ne sous-entends pas qu'il puisse s'agir d'un développeur OpenBSD; croyez-le ou non, il y a d'autres contributeurs) attribuait du code "illégal" à TNF. Je ne sais pas ce qu'en dirait la loi de l'Etat de New-York. En France ce serait de toute façon différent, TNF n'ayant pas d'incarnation légale.
Enfin bon, je m'en tape un peu des humeurs de mycroft, au final. Et Thunderbird ça me lourde.
Quentin Garnier.
(Désolé, je teste Thunderbird. Don't ask.)
[...]
Ah si: il faut lire cette saillie en sachant que la fondation NetBSD
(TNF) viens de décider de clore le compte de la dizaine de developpeurs
qui ont refusés de signer le developer agreement (un papier où on dit
qu'on est gentil et qu'on va pas faire n'importe quoi). Charles, qui est
là depuis une époque où ce genre de paperasse n'existait pas, n'a jamais
voulu le signer. Je trouve pour ma part un peu regrettable qu'un papier
à l'utilité douteuse nous mène à mettre dehors un important
contributeur. Mais d'un autre coté, l'incident révèle aussi une certaine
rigidité de la part de Charles: pourquoi refuser de signer ce truc,
après tout?
C'est marrant que tu perçoives les choses comme ça. C'est lui-même qui
a mis en place cette paperasserie justement, après avoir créé la fondation.
Aucun agreement n'a été perdu, c'est lui qui se les garde pour lui.
Je vois les choses différemment; Hannum s'est endormi pendant un moment
sur la Fondation et ne s'est réveillé qu'une fois que Zoulas eut fini de
terminer les paperasseries nécessaire à la continuité d'une telle
entité. Depuis il l'a mauvaise.
Il faut noter que l'agreement a une importance précise dans la mesure où
TNF est titulaire du copyright d'une grande partie du code. D'accord,
ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à
TNF pour du code d'origine pas forcément connue (du point de vue de TNF,
j'entends). Ce serait d'ailleurs un cas d'école assez marrant si un
quidam (ne me faites pas dire ce que je n'ai pas dit, je ne sous-entends
pas qu'il puisse s'agir d'un développeur OpenBSD; croyez-le ou non, il
y a d'autres contributeurs) attribuait du code "illégal" à TNF. Je ne
sais pas ce qu'en dirait la loi de l'Etat de New-York. En France ce
serait de toute façon différent, TNF n'ayant pas d'incarnation légale.
Enfin bon, je m'en tape un peu des humeurs de mycroft, au final. Et
Thunderbird ça me lourde.
Ah si: il faut lire cette saillie en sachant que la fondation NetBSD (TNF) viens de décider de clore le compte de la dizaine de developpeurs qui ont refusés de signer le developer agreement (un papier où on dit qu'on est gentil et qu'on va pas faire n'importe quoi). Charles, qui est là depuis une époque où ce genre de paperasse n'existait pas, n'a jamais voulu le signer. Je trouve pour ma part un peu regrettable qu'un papier à l'utilité douteuse nous mène à mettre dehors un important contributeur. Mais d'un autre coté, l'incident révèle aussi une certaine rigidité de la part de Charles: pourquoi refuser de signer ce truc, après tout?
C'est marrant que tu perçoives les choses comme ça. C'est lui-même qui a mis en place cette paperasserie justement, après avoir créé la fondation.
Aucun agreement n'a été perdu, c'est lui qui se les garde pour lui.
Je vois les choses différemment; Hannum s'est endormi pendant un moment sur la Fondation et ne s'est réveillé qu'une fois que Zoulas eut fini de terminer les paperasseries nécessaire à la continuité d'une telle entité. Depuis il l'a mauvaise.
Il faut noter que l'agreement a une importance précise dans la mesure où TNF est titulaire du copyright d'une grande partie du code. D'accord, ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à TNF pour du code d'origine pas forcément connue (du point de vue de TNF, j'entends). Ce serait d'ailleurs un cas d'école assez marrant si un quidam (ne me faites pas dire ce que je n'ai pas dit, je ne sous-entends pas qu'il puisse s'agir d'un développeur OpenBSD; croyez-le ou non, il y a d'autres contributeurs) attribuait du code "illégal" à TNF. Je ne sais pas ce qu'en dirait la loi de l'Etat de New-York. En France ce serait de toute façon différent, TNF n'ayant pas d'incarnation légale.
Enfin bon, je m'en tape un peu des humeurs de mycroft, au final. Et Thunderbird ça me lourde.
Quentin Garnier.
manu
Michel Talon wrote:
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de choses du même genre que les institutions dérivent vers le déclin et que les nuls prennent le pouvoir partout.
Oui, mais là il n'y a pas de pouvoir à conquerir, ni de décision à prendre. Nous sommes entre gens de bonne compagnie à parler de choses et d'autres, et je suis assez d'accord avec Fred: moi aussi je trouve tes recriminations agressives un peu fatigantes à lire. Note que je fais un effort et que je les lis quand même.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Merci Michel pour cette belle participation très constructive. C'est
plutôt fatiguant à lire, à la fin.
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de
choses du même genre que les institutions dérivent vers le déclin et que les
nuls prennent le pouvoir partout.
Oui, mais là il n'y a pas de pouvoir à conquerir, ni de décision à
prendre. Nous sommes entre gens de bonne compagnie à parler de choses et
d'autres, et je suis assez d'accord avec Fred: moi aussi je trouve tes
recriminations agressives un peu fatigantes à lire. Note que je fais un
effort et que je les lis quand même.
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de choses du même genre que les institutions dérivent vers le déclin et que les nuls prennent le pouvoir partout.
Oui, mais là il n'y a pas de pouvoir à conquerir, ni de décision à prendre. Nous sommes entre gens de bonne compagnie à parler de choses et d'autres, et je suis assez d'accord avec Fred: moi aussi je trouve tes recriminations agressives un peu fatigantes à lire. Note que je fais un effort et que je les lis quand même.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
F. Senault
F. Senault wrote:
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de choses du même genre que les institutions dérivent vers le déclin et que les nuls prennent le pouvoir partout. Mergemaster ne vaut rien,
C'est là que je décroche et que je commence à garnir mon scorefile.
Avec un programme qui ne vaudrait rien, je viens de mettre à jour trois machines ce soir. Ca m'a pris cinq minutes. Il n'est pas parfait, il pourrait être beaucoup mieux, mais ça me les casse menu de voir des opinions perpétuellement binaires.
Bref, je suis peut-être un béni oui-oui selon tes termes, mais je trouve que tes contributions font chuter à une vitesse alarmante la qualité de ce forum.
Fred -- If there were no desire to heal The damaged and broken met along This tedious path I've chosen here I certainly would've walked away by now. (Tool, The Patient)
F. Senault <fred@lacave.net> wrote:
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est
plutôt fatiguant à lire, à la fin.
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de
choses du même genre que les institutions dérivent vers le déclin et que les
nuls prennent le pouvoir partout. Mergemaster ne vaut rien,
C'est là que je décroche et que je commence à garnir mon scorefile.
Avec un programme qui ne vaudrait rien, je viens de mettre à jour trois
machines ce soir. Ca m'a pris cinq minutes. Il n'est pas parfait, il
pourrait être beaucoup mieux, mais ça me les casse menu de voir des
opinions perpétuellement binaires.
Bref, je suis peut-être un béni oui-oui selon tes termes, mais je trouve
que tes contributions font chuter à une vitesse alarmante la qualité de
ce forum.
Fred
--
If there were no desire to heal
The damaged and broken met along
This tedious path I've chosen here
I certainly would've walked away by now. (Tool, The Patient)
Bref, pour faire court, mergemaster est une bouse.
Merci Michel pour cette belle participation très constructive. C'est plutôt fatiguant à lire, à la fin.
Fred, c'est précisément à force de politesse, d'opinions nuancées, et de choses du même genre que les institutions dérivent vers le déclin et que les nuls prennent le pouvoir partout. Mergemaster ne vaut rien,
C'est là que je décroche et que je commence à garnir mon scorefile.
Avec un programme qui ne vaudrait rien, je viens de mettre à jour trois machines ce soir. Ca m'a pris cinq minutes. Il n'est pas parfait, il pourrait être beaucoup mieux, mais ça me les casse menu de voir des opinions perpétuellement binaires.
Bref, je suis peut-être un béni oui-oui selon tes termes, mais je trouve que tes contributions font chuter à une vitesse alarmante la qualité de ce forum.
Fred -- If there were no desire to heal The damaged and broken met along This tedious path I've chosen here I certainly would've walked away by now. (Tool, The Patient)
talon
F. Senault wrote:
C'est là que je décroche et que je commence à garnir mon scorefile.
Super! tu vois la différence entre toi et moi, outre que tu es certainement plus compétent, c'est que je n'utilise jamais de scorefile.
--
Michel TALON
F. Senault <fred@lacave.net> wrote:
C'est là que je décroche et que je commence à garnir mon scorefile.
Super! tu vois la différence entre toi et moi, outre que tu es certainement
plus compétent, c'est que je n'utilise jamais de scorefile.
