Marc Espie wrote:Apres, tu t'etonnes moins qu'il y ait des patchs non committes pour gcc sur
a peu pres toutes les archis un peu obscures: il y a tellement de red tape
au niveau de la FSF qu'une grosse partie des developpeurs opensource ont
totalement laisse tomber (rappel: on fait ca pour le fun, si on doit se
taper un process qui est encore plus chiant que celui de la SSII moyenne...)
C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
de plus en plus dependant d'autres outils gnu (par exemple, il reclame
gmake pour bootstrapper... tous les bsd ont du reverse-engineerer ca pour
faire un systeme de build sans gmake. Et on s'est vu opposer une fin de
non-recevoir a chaque fois qu'on a essaye d'enlever des gnu-makeries du
makefile officiel)...
Parce qu'aucun outil BSD n'utilise les extensions du make BSD ? Tant
qu'ils font l'effort que gmake soit portable...
Marc Espie wrote:
Apres, tu t'etonnes moins qu'il y ait des patchs non committes pour gcc sur
a peu pres toutes les archis un peu obscures: il y a tellement de red tape
au niveau de la FSF qu'une grosse partie des developpeurs opensource ont
totalement laisse tomber (rappel: on fait ca pour le fun, si on doit se
taper un process qui est encore plus chiant que celui de la SSII moyenne...)
C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
de plus en plus dependant d'autres outils gnu (par exemple, il reclame
gmake pour bootstrapper... tous les bsd ont du reverse-engineerer ca pour
faire un systeme de build sans gmake. Et on s'est vu opposer une fin de
non-recevoir a chaque fois qu'on a essaye d'enlever des gnu-makeries du
makefile officiel)...
Parce qu'aucun outil BSD n'utilise les extensions du make BSD ? Tant
qu'ils font l'effort que gmake soit portable...
Marc Espie wrote:Apres, tu t'etonnes moins qu'il y ait des patchs non committes pour gcc sur
a peu pres toutes les archis un peu obscures: il y a tellement de red tape
au niveau de la FSF qu'une grosse partie des developpeurs opensource ont
totalement laisse tomber (rappel: on fait ca pour le fun, si on doit se
taper un process qui est encore plus chiant que celui de la SSII moyenne...)
C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
de plus en plus dependant d'autres outils gnu (par exemple, il reclame
gmake pour bootstrapper... tous les bsd ont du reverse-engineerer ca pour
faire un systeme de build sans gmake. Et on s'est vu opposer une fin de
non-recevoir a chaque fois qu'on a essaye d'enlever des gnu-makeries du
makefile officiel)...
Parce qu'aucun outil BSD n'utilise les extensions du make BSD ? Tant
qu'ils font l'effort que gmake soit portable...
In article <hsh9nd$2b3h$, Marc wrote:C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
Ben c'est totalement anormal, justement. Le mouvement opensource, c'est
quand meme que tout le monde a acces et peut travailler dessus. T'as
qu'a lire les ecrits d'ESR par exemple.
Si ca se professionnalise et que ca devient difficile, voire impossible
de contribuer, c'est qu'il y a un gros probleme.
In article <hsh9nd$2b3h$1@nef.ens.fr>, Marc <marc.glisse@gmail.com> wrote:
C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
Ben c'est totalement anormal, justement. Le mouvement opensource, c'est
quand meme que tout le monde a acces et peut travailler dessus. T'as
qu'a lire les ecrits d'ESR par exemple.
Si ca se professionnalise et que ca devient difficile, voire impossible
de contribuer, c'est qu'il y a un gros probleme.
In article <hsh9nd$2b3h$, Marc wrote:C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
Ben c'est totalement anormal, justement. Le mouvement opensource, c'est
quand meme que tout le monde a acces et peut travailler dessus. T'as
qu'a lire les ecrits d'ESR par exemple.
Si ca se professionnalise et que ca devient difficile, voire impossible
de contribuer, c'est qu'il y a un gros probleme.
Marc Espie wrote:In article <hsh9nd$2b3h$, Marc wrote:C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
Ben c'est totalement anormal, justement. Le mouvement opensource, c'est
quand meme que tout le monde a acces et peut travailler dessus. T'as
qu'a lire les ecrits d'ESR par exemple.
Si ca se professionnalise et que ca devient difficile, voire impossible
de contribuer, c'est qu'il y a un gros probleme.
Euh, le fait que ça se professionnalise et la difficulté à contribuer
sont 2 choses différentes. D'ailleurs tu cites toi-même les exemples de
cmake et Qt (même si personnellement j'ai trouvé plus facile de
contribuer à gcc que Qt, mais les 2 datent un peu).
Je ne vois pas de problème en soi à ce que des développeurs soient payés
pour écrire du code libre.
Marc Espie wrote:
In article <hsh9nd$2b3h$1@nef.ens.fr>, Marc <marc.glisse@gmail.com> wrote:
C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
Ben c'est totalement anormal, justement. Le mouvement opensource, c'est
quand meme que tout le monde a acces et peut travailler dessus. T'as
qu'a lire les ecrits d'ESR par exemple.
Si ca se professionnalise et que ca devient difficile, voire impossible
de contribuer, c'est qu'il y a un gros probleme.
Euh, le fait que ça se professionnalise et la difficulté à contribuer
sont 2 choses différentes. D'ailleurs tu cites toi-même les exemples de
cmake et Qt (même si personnellement j'ai trouvé plus facile de
contribuer à gcc que Qt, mais les 2 datent un peu).
Je ne vois pas de problème en soi à ce que des développeurs soient payés
pour écrire du code libre.
Marc Espie wrote:In article <hsh9nd$2b3h$, Marc wrote:C'est un aspect révélateur de ta conception des choses, tu parles de
"développeur opensource" pour désigner les hobbyists, alors que la
majorité est professionnelle (ie payée pour, je ne fais pas de jugement
sur la qualité du boulot).
Ben c'est totalement anormal, justement. Le mouvement opensource, c'est
quand meme que tout le monde a acces et peut travailler dessus. T'as
qu'a lire les ecrits d'ESR par exemple.
Si ca se professionnalise et que ca devient difficile, voire impossible
de contribuer, c'est qu'il y a un gros probleme.
Euh, le fait que ça se professionnalise et la difficulté à contribuer
sont 2 choses différentes. D'ailleurs tu cites toi-même les exemples de
cmake et Qt (même si personnellement j'ai trouvé plus facile de
contribuer à gcc que Qt, mais les 2 datent un peu).
Je ne vois pas de problème en soi à ce que des développeurs soient payés
pour écrire du code libre.
Antoine Leca wrote:Le seul souci mais il est de taille, ce
sont (encore une fois) les usagers, qui « persistent » en nombre à
vouloir continuer à utiliser le langage C... et cela inclut des gros,
des énormes projets comme Windows. Bref, il faut faire avec.
Je ne suis pas sûr que ce soit le meilleur exemple, puisque microsoft
refuse d'implémenter C99 dans son compilateur C/C++, et ne s'est mis que
très récemment à ajouter des bouts de C99 en tant que C++0X.
Antoine Leca wrote:
Le seul souci mais il est de taille, ce
sont (encore une fois) les usagers, qui « persistent » en nombre à
vouloir continuer à utiliser le langage C... et cela inclut des gros,
des énormes projets comme Windows. Bref, il faut faire avec.
Je ne suis pas sûr que ce soit le meilleur exemple, puisque microsoft
refuse d'implémenter C99 dans son compilateur C/C++, et ne s'est mis que
très récemment à ajouter des bouts de C99 en tant que C++0X.
Antoine Leca wrote:Le seul souci mais il est de taille, ce
sont (encore une fois) les usagers, qui « persistent » en nombre à
vouloir continuer à utiliser le langage C... et cela inclut des gros,
des énormes projets comme Windows. Bref, il faut faire avec.
Je ne suis pas sûr que ce soit le meilleur exemple, puisque microsoft
refuse d'implémenter C99 dans son compilateur C/C++, et ne s'est mis que
très récemment à ajouter des bouts de C99 en tant que C++0X.
Pas encore degoute ? Alors on en ajoute encore. La politique de gcc,
en plus, depuis pas mal d'annees, c'est de ne jamais accepter de patchs
pour la version stable: il faut que tu fasses ton developpement en
-current, fasse accepter le patch en -current... pour apres pouvoir
dire que ton patch est critique, refaire un 2e patch en stable
Ne fais pas semblant de ne pas comprendre pourquoi ils font ça. Il est
gentil ton patch sur une vieille version, mais du coup il ne sera pas
dans la version suivante, donc il sera perdu, c'est la louze. Pour la
difficulté des backports pour une architecture non "prioritaire", je te
crois, mais dans ce cas tu te fais un arbre de sources qui suit la
release en question et où tu ajoutes tes patchs (je suis sûr que les BSD
font déjà ça). Puisque que tu les as mis dans le trunk de gcc, ils seront
dans la prochaine release officielle, et ton projet propose sa propre
version patchée de la vieille version stable. Oui c'est un peu de
travail.
Pas encore degoute ? Alors on en ajoute encore. La politique de gcc,
en plus, depuis pas mal d'annees, c'est de ne jamais accepter de patchs
pour la version stable: il faut que tu fasses ton developpement en
-current, fasse accepter le patch en -current... pour apres pouvoir
dire que ton patch est critique, refaire un 2e patch en stable
Ne fais pas semblant de ne pas comprendre pourquoi ils font ça. Il est
gentil ton patch sur une vieille version, mais du coup il ne sera pas
dans la version suivante, donc il sera perdu, c'est la louze. Pour la
difficulté des backports pour une architecture non "prioritaire", je te
crois, mais dans ce cas tu te fais un arbre de sources qui suit la
release en question et où tu ajoutes tes patchs (je suis sûr que les BSD
font déjà ça). Puisque que tu les as mis dans le trunk de gcc, ils seront
dans la prochaine release officielle, et ton projet propose sa propre
version patchée de la vieille version stable. Oui c'est un peu de
travail.
Pas encore degoute ? Alors on en ajoute encore. La politique de gcc,
en plus, depuis pas mal d'annees, c'est de ne jamais accepter de patchs
pour la version stable: il faut que tu fasses ton developpement en
-current, fasse accepter le patch en -current... pour apres pouvoir
dire que ton patch est critique, refaire un 2e patch en stable
Ne fais pas semblant de ne pas comprendre pourquoi ils font ça. Il est
gentil ton patch sur une vieille version, mais du coup il ne sera pas
dans la version suivante, donc il sera perdu, c'est la louze. Pour la
difficulté des backports pour une architecture non "prioritaire", je te
crois, mais dans ce cas tu te fais un arbre de sources qui suit la
release en question et où tu ajoutes tes patchs (je suis sûr que les BSD
font déjà ça). Puisque que tu les as mis dans le trunk de gcc, ils seront
dans la prochaine release officielle, et ton projet propose sa propre
version patchée de la vieille version stable. Oui c'est un peu de
travail.
Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Marc Espie wrote:Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Merci pour l'exemple et les explications, c'est beaucoup plus clair.Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Enfin il a été fermé quand la branche a été abandonnée, ce qui s'est
produit presque 2 ans après la dernière activité sur ce bug. Donc dans ce
cas très précis, le plus gros problème est qu'en 2 ans personne n'a été
assez motivé/compétent pour corriger le bug. Mais je comprends ce que tu
veux montrer.
Marc Espie wrote:
Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Merci pour l'exemple et les explications, c'est beaucoup plus clair.
Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Enfin il a été fermé quand la branche a été abandonnée, ce qui s'est
produit presque 2 ans après la dernière activité sur ce bug. Donc dans ce
cas très précis, le plus gros problème est qu'en 2 ans personne n'a été
assez motivé/compétent pour corriger le bug. Mais je comprends ce que tu
veux montrer.
Marc Espie wrote:Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Merci pour l'exemple et les explications, c'est beaucoup plus clair.Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Enfin il a été fermé quand la branche a été abandonnée, ce qui s'est
produit presque 2 ans après la dernière activité sur ce bug. Donc dans ce
cas très précis, le plus gros problème est qu'en 2 ans personne n'a été
assez motivé/compétent pour corriger le bug. Mais je comprends ce que tu
veux montrer.
In article <hsn6h6$p8u$, Marc wrote:Marc Espie wrote:Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Merci pour l'exemple et les explications, c'est beaucoup plus clair.Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Enfin il a été fermé quand la branche a été abandonnée, ce qui s'est
produit presque 2 ans après la dernière activité sur ce bug. Donc dans ce
cas très précis, le plus gros problème est qu'en 2 ans personne n'a été
assez motivé/compétent pour corriger le bug. Mais je comprends ce que tu
veux montrer.
Probleme de motivation, en l'occurrence.
Il y a des gens tres competents pour toujours aller de l'avant sur
la derniere version, qui est forcement plus sexe.
Si tu regardes sur le bugzilla, c'est impressionnant le nombre de bugs non
corriges en 4.2* qui ont ete fermes par l'abandon de la branche et "doesn't
occur in 4.3". En terme de qualite du soft, c'est catastrophique: t'as un
compilo qui en fait contient pas mal de problemes (la plupart se produisant
ailleurs que sur la plateforme de references), mais ceux-ci ne sont jamais
corriges, parce que les gens preferent bosser sur la version suivante... qui
va contenir des bugs differents, parce que le code a tout change.
On a deja constate le probleme par le passe, avec propolice. Il y a un
-fstack-protector dans openbsd, meme si le compilo systeme y etait un gcc
3.3. Faire propolice, ca n'etait fondamentalement pas complique (encore que,
visiblement, les gens qui ont fait ca etaient plus doues que les manches
actuels dans gcc, vu que ca ne marche pas sur alpha chez eux). Ce qui a ete
dur, c'est de corriger les multiples bugs que ca declenchait AILLEURS dans
gcc: suffisait de prendre autre chose que les codepaths bien testes par les
options "classiques" de gcc pour declencher des problemes...
In article <hsn6h6$p8u$1@nef.ens.fr>, Marc <marc.glisse@gmail.com> wrote:
Marc Espie wrote:
Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Merci pour l'exemple et les explications, c'est beaucoup plus clair.
Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Enfin il a été fermé quand la branche a été abandonnée, ce qui s'est
produit presque 2 ans après la dernière activité sur ce bug. Donc dans ce
cas très précis, le plus gros problème est qu'en 2 ans personne n'a été
assez motivé/compétent pour corriger le bug. Mais je comprends ce que tu
veux montrer.
Probleme de motivation, en l'occurrence.
Il y a des gens tres competents pour toujours aller de l'avant sur
la derniere version, qui est forcement plus sexe.
Si tu regardes sur le bugzilla, c'est impressionnant le nombre de bugs non
corriges en 4.2* qui ont ete fermes par l'abandon de la branche et "doesn't
occur in 4.3". En terme de qualite du soft, c'est catastrophique: t'as un
compilo qui en fait contient pas mal de problemes (la plupart se produisant
ailleurs que sur la plateforme de references), mais ceux-ci ne sont jamais
corriges, parce que les gens preferent bosser sur la version suivante... qui
va contenir des bugs differents, parce que le code a tout change.
On a deja constate le probleme par le passe, avec propolice. Il y a un
-fstack-protector dans openbsd, meme si le compilo systeme y etait un gcc
3.3. Faire propolice, ca n'etait fondamentalement pas complique (encore que,
visiblement, les gens qui ont fait ca etaient plus doues que les manches
actuels dans gcc, vu que ca ne marche pas sur alpha chez eux). Ce qui a ete
dur, c'est de corriger les multiples bugs que ca declenchait AILLEURS dans
gcc: suffisait de prendre autre chose que les codepaths bien testes par les
options "classiques" de gcc pour declencher des problemes...
In article <hsn6h6$p8u$, Marc wrote:Marc Espie wrote:Tiens, je viens de tomber sur un exemple qui illustre bien le souci:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id2544
un bug-report precis, sur une regression qui affecte la branche 4.2* par
rapport a la branche 4.1, et qui a ete corrige en 4.3.
Merci pour l'exemple et les explications, c'est beaucoup plus clair.Au final, le bug a ete ferme. Pourquoi ? pas parce qu'il a ete corrige, mais
parce que la branche 4.3 fait des trucs differemment, et n'exhibe plus le
probleme...
Enfin il a été fermé quand la branche a été abandonnée, ce qui s'est
produit presque 2 ans après la dernière activité sur ce bug. Donc dans ce
cas très précis, le plus gros problème est qu'en 2 ans personne n'a été
assez motivé/compétent pour corriger le bug. Mais je comprends ce que tu
veux montrer.
Probleme de motivation, en l'occurrence.
Il y a des gens tres competents pour toujours aller de l'avant sur
la derniere version, qui est forcement plus sexe.
Si tu regardes sur le bugzilla, c'est impressionnant le nombre de bugs non
corriges en 4.2* qui ont ete fermes par l'abandon de la branche et "doesn't
occur in 4.3". En terme de qualite du soft, c'est catastrophique: t'as un
compilo qui en fait contient pas mal de problemes (la plupart se produisant
ailleurs que sur la plateforme de references), mais ceux-ci ne sont jamais
corriges, parce que les gens preferent bosser sur la version suivante... qui
va contenir des bugs differents, parce que le code a tout change.
On a deja constate le probleme par le passe, avec propolice. Il y a un
-fstack-protector dans openbsd, meme si le compilo systeme y etait un gcc
3.3. Faire propolice, ca n'etait fondamentalement pas complique (encore que,
visiblement, les gens qui ont fait ca etaient plus doues que les manches
actuels dans gcc, vu que ca ne marche pas sur alpha chez eux). Ce qui a ete
dur, c'est de corriger les multiples bugs que ca declenchait AILLEURS dans
gcc: suffisait de prendre autre chose que les codepaths bien testes par les
options "classiques" de gcc pour declencher des problemes...
Nous somems bien d'accord, encore que ma vision d'OpenBSD n'est pas
aussi idéalisée que la tienne (il y a longtemps que je ne porte plus
mes codes sous OpenBSD tellement j'ai de problèmes avec ce système.
Net ou Free, c'est bien, Open... Passons...).
Nous somems bien d'accord, encore que ma vision d'OpenBSD n'est pas
aussi idéalisée que la tienne (il y a longtemps que je ne porte plus
mes codes sous OpenBSD tellement j'ai de problèmes avec ce système.
Net ou Free, c'est bien, Open... Passons...).
Nous somems bien d'accord, encore que ma vision d'OpenBSD n'est pas
aussi idéalisée que la tienne (il y a longtemps que je ne porte plus
mes codes sous OpenBSD tellement j'ai de problèmes avec ce système.
Net ou Free, c'est bien, Open... Passons...).
In article ,
JKB wrote:Nous somems bien d'accord, encore que ma vision d'OpenBSD n'est pas
aussi idéalisée que la tienne (il y a longtemps que je ne porte plus
mes codes sous OpenBSD tellement j'ai de problèmes avec ce système.
Net ou Free, c'est bien, Open... Passons...).
Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)
In article <slrnhuvb82.e0f.knatschke@rayleigh.systella.fr>,
JKB <wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com> wrote:
Nous somems bien d'accord, encore que ma vision d'OpenBSD n'est pas
aussi idéalisée que la tienne (il y a longtemps que je ne porte plus
mes codes sous OpenBSD tellement j'ai de problèmes avec ce système.
Net ou Free, c'est bien, Open... Passons...).
Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)
In article ,
JKB wrote:Nous somems bien d'accord, encore que ma vision d'OpenBSD n'est pas
aussi idéalisée que la tienne (il y a longtemps que je ne porte plus
mes codes sous OpenBSD tellement j'ai de problèmes avec ce système.
Net ou Free, c'est bien, Open... Passons...).
Ca depend pas mal de ce que tu fais, j'aimerais bien des details sur les
problemes que tu vois. (bon, si c'est des problemes de locale, on est
chroniquement a la traine...)
(on est conscients de certaines des limitations de ce qu'on fait, mais ca
progresse de facon mesurable d'une version a la suivante)