F. Senault n'était pas loin de dire :[...] Comment veux-tu arrêter de soutenir le projet ? Ordonner au mec
de se mettre à bosser sur PC parce que c'est plus porteur ? Tu crois
vraiment que tu vas *récupérer* quelqu'un dans l'open source, ou juste
le voir se barrer ailleurs avec son fork ?
Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ? Michel Talon exagérait en parlant de machine que l'on ne
trouvait plus que dans les musées, mais crois-tu vraiment que les
développeurs qui s'occupent du support pour Vax ne sont que des
fanatiques de Vax et ne seraient pas prêt à bosser aussi sur, disons
les Sun, qu'ils ont aussi à disposition ?
De plus tu réduis le problème aux cas particuliers des architectures
soutenues, oubliant l'ensemble du projet. Si les développeurs Vax fork
et créent un BSD purement Vax synchronisé sur NetBSD, pourquoi pas.
Dans le même temps, NetBSD n'aura plus à attendre qu'ils aient adapté
les modifications avant de pouvoir passer à la suite.
De même, qu'est-ce qu'ils en ont à faire, eux, du SMP ou de ceci/cela
? Comment une équipe peut-elle avancer dans une direction si la moitié
de ses membres n'en ont rien à faire de cette direction et se tourne
donc les pouces (façon de parler) ? Amha ça n'aide pas vraiment à avoir
une bonne ambiance.
F. Senault n'était pas loin de dire :
[...] Comment veux-tu arrêter de soutenir le projet ? Ordonner au mec
de se mettre à bosser sur PC parce que c'est plus porteur ? Tu crois
vraiment que tu vas *récupérer* quelqu'un dans l'open source, ou juste
le voir se barrer ailleurs avec son fork ?
Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ? Michel Talon exagérait en parlant de machine que l'on ne
trouvait plus que dans les musées, mais crois-tu vraiment que les
développeurs qui s'occupent du support pour Vax ne sont que des
fanatiques de Vax et ne seraient pas prêt à bosser aussi sur, disons
les Sun, qu'ils ont aussi à disposition ?
De plus tu réduis le problème aux cas particuliers des architectures
soutenues, oubliant l'ensemble du projet. Si les développeurs Vax fork
et créent un BSD purement Vax synchronisé sur NetBSD, pourquoi pas.
Dans le même temps, NetBSD n'aura plus à attendre qu'ils aient adapté
les modifications avant de pouvoir passer à la suite.
De même, qu'est-ce qu'ils en ont à faire, eux, du SMP ou de ceci/cela
? Comment une équipe peut-elle avancer dans une direction si la moitié
de ses membres n'en ont rien à faire de cette direction et se tourne
donc les pouces (façon de parler) ? Amha ça n'aide pas vraiment à avoir
une bonne ambiance.
F. Senault n'était pas loin de dire :[...] Comment veux-tu arrêter de soutenir le projet ? Ordonner au mec
de se mettre à bosser sur PC parce que c'est plus porteur ? Tu crois
vraiment que tu vas *récupérer* quelqu'un dans l'open source, ou juste
le voir se barrer ailleurs avec son fork ?
Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ? Michel Talon exagérait en parlant de machine que l'on ne
trouvait plus que dans les musées, mais crois-tu vraiment que les
développeurs qui s'occupent du support pour Vax ne sont que des
fanatiques de Vax et ne seraient pas prêt à bosser aussi sur, disons
les Sun, qu'ils ont aussi à disposition ?
De plus tu réduis le problème aux cas particuliers des architectures
soutenues, oubliant l'ensemble du projet. Si les développeurs Vax fork
et créent un BSD purement Vax synchronisé sur NetBSD, pourquoi pas.
Dans le même temps, NetBSD n'aura plus à attendre qu'ils aient adapté
les modifications avant de pouvoir passer à la suite.
De même, qu'est-ce qu'ils en ont à faire, eux, du SMP ou de ceci/cela
? Comment une équipe peut-elle avancer dans une direction si la moitié
de ses membres n'en ont rien à faire de cette direction et se tourne
donc les pouces (façon de parler) ? Amha ça n'aide pas vraiment à avoir
une bonne ambiance.
Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ?
Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ?
Tu connais beaucoup de personnes qui n'ont que du Vax à disposition,
par exemple ?
ne les paratage pas. Du coup, les tentatives de fork que furent
EkkoBSD, MirBSD et dans une (nette) moindre mesure MicroBSD ont
échoués. Si le premier existe peut-être encore (quelqu'un pourrait le
dire ?), MirBSD n'en fini pas de se chercher, et MicroBSD ressemblait
plus à une vengeance contre Théo qu'autre chose.
ne les paratage pas. Du coup, les tentatives de fork que furent
EkkoBSD, MirBSD et dans une (nette) moindre mesure MicroBSD ont
échoués. Si le premier existe peut-être encore (quelqu'un pourrait le
dire ?), MirBSD n'en fini pas de se chercher, et MicroBSD ressemblait
plus à une vengeance contre Théo qu'autre chose.
ne les paratage pas. Du coup, les tentatives de fork que furent
EkkoBSD, MirBSD et dans une (nette) moindre mesure MicroBSD ont
échoués. Si le premier existe peut-être encore (quelqu'un pourrait le
dire ?), MirBSD n'en fini pas de se chercher, et MicroBSD ressemblait
plus à une vengeance contre Théo qu'autre chose.
J'avais essayé de faire un desktop sous NetBSD, c'est largement
faisable. Le vrai problème àma c'est la mise à jour des ports, il
manque un outil du genre portupgrade.
J'avais essayé de faire un desktop sous NetBSD, c'est largement
faisable. Le vrai problème àma c'est la mise à jour des ports, il
manque un outil du genre portupgrade.
J'avais essayé de faire un desktop sous NetBSD, c'est largement
faisable. Le vrai problème àma c'est la mise à jour des ports, il
manque un outil du genre portupgrade.
Hélàs je penche pour cette solution. Il y aurait un gros travail de
packaging et de pre-configuration des applis de bureautique pour qu'un
BSD soit lambda-friendly.
Bof. J'ai passé une semaine pour configurer X.org, mais c'est
uniquement parce que je suis tétu. Lorsqu'il utilisait la configuration
par défaut (i.e. sans fichier de conf extérieur) il fonctionnait à
merveille, même si les performances étaient un peu dégradée. C'est très
user-friendly façon Microsoft ça.
Hélàs je penche pour cette solution. Il y aurait un gros travail de
packaging et de pre-configuration des applis de bureautique pour qu'un
BSD soit lambda-friendly.
Bof. J'ai passé une semaine pour configurer X.org, mais c'est
uniquement parce que je suis tétu. Lorsqu'il utilisait la configuration
par défaut (i.e. sans fichier de conf extérieur) il fonctionnait à
merveille, même si les performances étaient un peu dégradée. C'est très
user-friendly façon Microsoft ça.
Hélàs je penche pour cette solution. Il y aurait un gros travail de
packaging et de pre-configuration des applis de bureautique pour qu'un
BSD soit lambda-friendly.
Bof. J'ai passé une semaine pour configurer X.org, mais c'est
uniquement parce que je suis tétu. Lorsqu'il utilisait la configuration
par défaut (i.e. sans fichier de conf extérieur) il fonctionnait à
merveille, même si les performances étaient un peu dégradée. C'est très
user-friendly façon Microsoft ça.
Incidemment, j'ai trouvé les documentations de NetBSD que j'ai vues
excellentes - et généralement plus pointues et précises que celles de
FreeBSD. Mais prétendre qu'il faut avoir lu la documentation pour installer et
utiliser un système c'est de la folie furieuse.
Incidemment, j'ai trouvé les documentations de NetBSD que j'ai vues
excellentes - et généralement plus pointues et précises que celles de
FreeBSD. Mais prétendre qu'il faut avoir lu la documentation pour installer et
utiliser un système c'est de la folie furieuse.
Incidemment, j'ai trouvé les documentations de NetBSD que j'ai vues
excellentes - et généralement plus pointues et précises que celles de
FreeBSD. Mais prétendre qu'il faut avoir lu la documentation pour installer et
utiliser un système c'est de la folie furieuse.
Il me semble que des outils de la convivialité de mergemaster auraient
pourtant du dissuader l'auteur de sévir à nouveau.
Quel est le problème avec mergemaster ?
C'est imbouffable. Une fois sur deux je me demande si je suis entrain
de garder mes modifications ou de tout foutre en l'air. Et une fois sur
trois je suis vraiment entrain de tout foutre en l'air.
Il me semble que des outils de la convivialité de mergemaster auraient
pourtant du dissuader l'auteur de sévir à nouveau.
Quel est le problème avec mergemaster ?
C'est imbouffable. Une fois sur deux je me demande si je suis entrain
de garder mes modifications ou de tout foutre en l'air. Et une fois sur
trois je suis vraiment entrain de tout foutre en l'air.
Il me semble que des outils de la convivialité de mergemaster auraient
pourtant du dissuader l'auteur de sévir à nouveau.
Quel est le problème avec mergemaster ?
C'est imbouffable. Une fois sur deux je me demande si je suis entrain
de garder mes modifications ou de tout foutre en l'air. Et une fois sur
trois je suis vraiment entrain de tout foutre en l'air.
Bonjour,
le 10/09/2006 à 13:11, Michel Talon a écrit dans le message
<ee0rtb$12ai$ :Il me semble que des outils de la convivialité de mergemaster auraient
pourtant du dissuader l'auteur de sévir à nouveau.
Quel est le problème avec mergemaster ?
Bonjour,
le 10/09/2006 à 13:11, Michel Talon a écrit dans le message
<ee0rtb$12ai$1@asmodee.lpthe.jussieu.fr> :
Il me semble que des outils de la convivialité de mergemaster auraient
pourtant du dissuader l'auteur de sévir à nouveau.
Quel est le problème avec mergemaster ?
Bonjour,
le 10/09/2006 à 13:11, Michel Talon a écrit dans le message
<ee0rtb$12ai$ :Il me semble que des outils de la convivialité de mergemaster auraient
pourtant du dissuader l'auteur de sévir à nouveau.
Quel est le problème avec mergemaster ?
Et c'est là où je ne suis pas d'accord avec Michel
Talon.
Faire une version en français d'un document n'est pas une perte de
temps, mais plutôt un moyen de montrer que ce n'est pas aussi compliqué
qu'il ne peut y paraître au premier abord. Et tant pis si dans un
premier temps il n'y a que trois lecteurs.
Et c'est là où je ne suis pas d'accord avec Michel
Talon.
Faire une version en français d'un document n'est pas une perte de
temps, mais plutôt un moyen de montrer que ce n'est pas aussi compliqué
qu'il ne peut y paraître au premier abord. Et tant pis si dans un
premier temps il n'y a que trois lecteurs.
Et c'est là où je ne suis pas d'accord avec Michel
Talon.
Faire une version en français d'un document n'est pas une perte de
temps, mais plutôt un moyen de montrer que ce n'est pas aussi compliqué
qu'il ne peut y paraître au premier abord. Et tant pis si dans un
premier temps il n'y a que trois lecteurs.
Un projet comme NetBSD n'a pas à proprement parler de direction
technique qui établit ce qui doit évoluer et comment. C'est bien plus
les contributions des individus qui pilotent le projet, ce qui laisse
pas mal de la place au p'tit nouveau qui veut s'exprimer.
Mais cela fait aussi que, soit le projet (i.e. tous projets gérés de
cette façon) part dans tous les sens, soit il tend à stagner. De plus,
qu'est-ce qui fait que NetBSD diffère à ce point d'autres projets
disposant eux d'une direction technique, quelque soit sa forme ? Je ne
vois pas pourquoi, si ce n'est pour des raisons historiques et/ou
peut-être d'égo, NetBSD ne pourrait pas se tourner vers cette forme.
D'ailleurs comment pourrait il en être autrement, dans un projet de
bénévoles?
Linux, OpenBSD, etc. ne sont pas des projets de bénévoles ?
Une direction technique ne peut imposer une évolution sans
disposer de resources humaines pour la mettre en oeuvre.
Une direction technique n'est pas à proprement parler là pour imposer
quoi que ce soit, mais pour préparer le terrain. Il est plus facile de
discuter à dix de la faisabilité d'une proposition et de la façon dont
elle doit être mise en oeuvre, que d'avoir la même discussion avec
quelques centaines de personnes peuvent donner leur avis. La dizaine de
personne à la tête du projet fini par se connaitre, par comprendre ce
qui se trouve entre les lignes, ce qui facilite les discussions et
permet d'arriver rapidement à une conclusion.
Un projet comme NetBSD n'a pas à proprement parler de direction
technique qui établit ce qui doit évoluer et comment. C'est bien plus
les contributions des individus qui pilotent le projet, ce qui laisse
pas mal de la place au p'tit nouveau qui veut s'exprimer.
Mais cela fait aussi que, soit le projet (i.e. tous projets gérés de
cette façon) part dans tous les sens, soit il tend à stagner. De plus,
qu'est-ce qui fait que NetBSD diffère à ce point d'autres projets
disposant eux d'une direction technique, quelque soit sa forme ? Je ne
vois pas pourquoi, si ce n'est pour des raisons historiques et/ou
peut-être d'égo, NetBSD ne pourrait pas se tourner vers cette forme.
D'ailleurs comment pourrait il en être autrement, dans un projet de
bénévoles?
Linux, OpenBSD, etc. ne sont pas des projets de bénévoles ?
Une direction technique ne peut imposer une évolution sans
disposer de resources humaines pour la mettre en oeuvre.
Une direction technique n'est pas à proprement parler là pour imposer
quoi que ce soit, mais pour préparer le terrain. Il est plus facile de
discuter à dix de la faisabilité d'une proposition et de la façon dont
elle doit être mise en oeuvre, que d'avoir la même discussion avec
quelques centaines de personnes peuvent donner leur avis. La dizaine de
personne à la tête du projet fini par se connaitre, par comprendre ce
qui se trouve entre les lignes, ce qui facilite les discussions et
permet d'arriver rapidement à une conclusion.
Un projet comme NetBSD n'a pas à proprement parler de direction
technique qui établit ce qui doit évoluer et comment. C'est bien plus
les contributions des individus qui pilotent le projet, ce qui laisse
pas mal de la place au p'tit nouveau qui veut s'exprimer.
Mais cela fait aussi que, soit le projet (i.e. tous projets gérés de
cette façon) part dans tous les sens, soit il tend à stagner. De plus,
qu'est-ce qui fait que NetBSD diffère à ce point d'autres projets
disposant eux d'une direction technique, quelque soit sa forme ? Je ne
vois pas pourquoi, si ce n'est pour des raisons historiques et/ou
peut-être d'égo, NetBSD ne pourrait pas se tourner vers cette forme.
D'ailleurs comment pourrait il en être autrement, dans un projet de
bénévoles?
Linux, OpenBSD, etc. ne sont pas des projets de bénévoles ?
Une direction technique ne peut imposer une évolution sans
disposer de resources humaines pour la mettre en oeuvre.
Une direction technique n'est pas à proprement parler là pour imposer
quoi que ce soit, mais pour préparer le terrain. Il est plus facile de
discuter à dix de la faisabilité d'une proposition et de la façon dont
elle doit être mise en oeuvre, que d'avoir la même discussion avec
quelques centaines de personnes peuvent donner leur avis. La dizaine de
personne à la tête du projet fini par se connaitre, par comprendre ce
qui se trouve entre les lignes, ce qui facilite les discussions et
permet d'arriver rapidement à une conclusion.
