Un truc qui me tracasse sur le libre.

Thierry Boudet

09/03/2006 à 14:12

On 2006-03-08, Antoine Leca wrote:

famées). Ah, et les "virus" en question visait aussi bien (en fait aussi
mal) Linux que Windows. Au deuxième virus, j'ai d'ailleurs changer de

Des détails sur le virus multiplateforme ?

Est-ce que tu considères que les pilotes de périphériques font partie du
noyau ? Si oui, ce n'est plus le cas depuis plusieurs années déjà...

Des détails sur la séparation driver/kernel ?

--
Le kernel ? un 2.4.17-mdk-patch-level-42-1984-de-la-mort-qui-tue ?
Moi c'est un FreeBSD 3.1R et un 4.5R. C'est clair et net au moins.
Alors, inutile de parler de Windows en plein bordel Linuxien.
-- TP, dans fcol.debats --

Thierry Boudet

09/03/2006 à 14:22

On 2006-03-05, R12y wrote:

logiciel libre à Windows on peut carrément dire qu'un windows de base +
une offre logicielle sur un CD annexe permet d'avoir un système qui met la
paté à n'importe quelle distribution Linux.

Chacun est libre de copuler avec le démon.

Et moi, ça m'embarrasse...

Enfile un anti-virus.

--
"Le médecin, depuis qu'il a l'ordinateur, quand il te parle, il te
regarde plus : il regarde son ordinateur avec une tronche, mon pauvre,
on dirait qu'il a bouffé un ver."

Thierry Boudet

09/03/2006 à 14:34

On 2006-03-08, Don Guy Shot wrote:

D'accord, ce serait pour des raisons uniquement marketing. Et alors ?

Et alors ? Alors, ils continueront à faire de la merde.

--

Errare humanum est, ...
Sed persevere diabolicum :)
:~$ sed persevere diabolicum

sed: -e expression #1, char 2: extra characters after command

Antoine Leca

09/03/2006 à 16:19

En news:, Franck Yvonnet va escriure:

l'Administration, bin elle ne laisse pas le choix...

Comme dirais Stephane, tu peux toujours t'expatrier :-)

Encore :-)

Tu sais d'où j'écris, ou c'est un hasard ?

Antoine

Antoine Leca

09/03/2006 à 16:51

En news:dun6qb$23kr$, Nicolas George va escriure:

Et je ne parle pas de la diffusion de l'ouvre pour laquelle ils ont
contribué le morceau de code (qui est clairement sous GPL), mais des
autres ouvres parallèles de l'auteur original (désolé pour
l'expression malheureuse, j'espère que l'idée reste claire).

Ah bon, première nouvelle. Je croyais qu'on parlait du fait qu'un
auteur qui accepte une contribution tierce dans un code qu'il a
distribué sous GPL perd la possibilité de distribuer sous une autre
licence sans l'accord du contributeur.

Bin oui, on parle bien de la même chose.
J'essaye de comprendre pourquoi le fait que l'ouvre soit diffusée sous GPL
change le régime juridique des autres diffusions (en gros, les interdit, y
compris pour l'auteur original qui a placé l'ouvre en GPL).

Par ailleurs, j'ai du mal à imaginer l'applicabilité pratique de ce
que tu décris ; par contre, si on considère l'ouvre comme
collective, cela devient beaucoup plus facile à imaginer...

Le terme correct est oeuvre de collaboration, ce qui est différent
d'oeuvre collective. Et ça revient à ce que je dis : la diffusion
doit être autorisée par tous les auteurs.

Je sais bien que ce que tu décris s'appelle une ouvre de collaboration. Ce
que je cherche, c'est ce qui motive la qualification d'une contribution de
10 lignes comme ouvre de collaboration, et non pas comme ouvre collective,
dirigée par l'auteur, que par ailleurs tout le monde connaît et identifie
comme tel.

Je sais bien qu'avec les outils actuels de suivi de code et autre Changelog,
on peut identifier a posteriori Toto Contributeur comme auteur des 10 lignes
dans le résultat final. Mais on peut aussi resssortir d'une encyclopédie qui
est celui qui a écrit tel ou tel bout d'article : cependant, il est
généralement considéré qu'une encyclopédie est une ouvre collective.

Ça marche dans les deux sens : Toto Contributeur dit à l'auteur « tu
acceptes mon patch sous _mes_ conditions, et si tu n'es pas content
tu n'as qu'à refaire le boulot toi-même. ».
Euh, non, cela je ne le prends pas.

Pas compris. Qu'est-ce que tu ne prends pas ?

Bin, en tant que contributeur je n'ai jamais vu la possibilité d'exprimer de
telles conditions... (ni la moindre condition, d'ailleurs.)
En gros, soit j'adhère intégralement à la charte ou les éléments disponibles
(qui ne constitue absolument pas un contrat), soit je n'envois pas.

En fait si, il y a bien un moyen de poser les conditions, comme je le
mentionnais auparavant : c'est de mettre _explicitement_ le patch sous GPL.
Là, c'est clair, et effectivement si l'auteur accepte le patch l'ouvre est
verrouillée sous GPL (sauf postérieure rétractation explicite de Toto).

Mais si j'ai bien compris qu'en fait tu sous-entends « je contribue
à ton logiciel que sous la promesse que tu le gardes libre », pour
moi cela ne marche pas, en tous cas je ne trouve pas cela évident
(en droit, moralement c'est autre chose).

Non, ce n'est pas ça. Ce que c'est, c'est : « Je contribue à ton
logiciel, et si tu acceptes, ça devient _notre_ logiciel. Et je te
préviens, je n'accepterai pas d'autre licence que la GPL. ».

Oui, cela c'est ton avis, mais c'est cela que je ne vois pas clairement,
sauf à le préciser explicitement.

D'abord, je fais une différence à ce niveau entre un patch qui
précise explicitement (ou implicitement au travers des conditions du
projet, un peu genre le contrat Debian) "ce patch est placé sous
GPL", et un autre qui ne le fait pas. Dans la pratique, je vois
passer les deux.

Un patch à un logiciel sous GPL par quelqu'un d'autre que le
titulaire du copyright de la partie patchée est toujours
implicitement sous GPL, puisque la licence du logiciel interdit d'en
reditstribuer des versions modifiées autrement que sous GPL, et que
le patch est précisément une version modifiée.

Non.
La diffusion par l'auteur du patch (Toto) de l'assemblage de la version
originale et de son patch est effectivement sous GPL (ce qui permet la
continuité du projet). Mais on ne parle pas de cela ici.

Parce que si ce que tu écrivais ci-dessus était correct, il serait
absolument impossible d'avoir des logiciels avec deux licences, GPL et autre
chose (disons MIT).

Par ailleurs, juridiquement « logiciel sous GPL » je ne vois pas comment
cela affecte le logiciel en tant que tel (cela affecte sa redistribution, là
on est d'accord, mais c'est autre chose).

Il est évidemment question de patches non triviaux.

Mais pour moi, la limite de 10 lignes est historiquement est une observation
empirique des auteurs de XxxBSD pour être sûr de bien englober, par excès,
toutes les contributions non triviales, ou plus exactement une manière
d'éviter de perdre du temps à considérer les patchs triviaux dans les
problèmes de droits d'auteur. Je ne trouve pas correct de l'utiliser telle
quelle pour caractériser ce qui constitue une ouvre de l'esprit.

Si tu remplaces cela par les définitions pertinentes du CPI, on serait
d'accord.

Antoine

En news:dun6qb$23kr$1@nef.ens.fr, Nicolas George va escriure:

Et je ne parle pas de la diffusion de l'ouvre pour laquelle ils ont
contribué le morceau de code (qui est clairement sous GPL), mais des
autres ouvres parallèles de l'auteur original (désolé pour
l'expression malheureuse, j'espère que l'idée reste claire).

Ah bon, première nouvelle. Je croyais qu'on parlait du fait qu'un
auteur qui accepte une contribution tierce dans un code qu'il a
distribué sous GPL perd la possibilité de distribuer sous une autre
licence sans l'accord du contributeur.

Bin oui, on parle bien de la même chose.
J'essaye de comprendre pourquoi le fait que l'ouvre soit diffusée sous GPL
change le régime juridique des autres diffusions (en gros, les interdit, y
compris pour l'auteur original qui a placé l'ouvre en GPL).

Par ailleurs, j'ai du mal à imaginer l'applicabilité pratique de ce
que tu décris ; par contre, si on considère l'ouvre comme
collective, cela devient beaucoup plus facile à imaginer...

Le terme correct est oeuvre de collaboration, ce qui est différent
d'oeuvre collective. Et ça revient à ce que je dis : la diffusion
doit être autorisée par tous les auteurs.

Je sais bien que ce que tu décris s'appelle une ouvre de collaboration. Ce
que je cherche, c'est ce qui motive la qualification d'une contribution de
10 lignes comme ouvre de collaboration, et non pas comme ouvre collective,
dirigée par l'auteur, que par ailleurs tout le monde connaît et identifie
comme tel.

Je sais bien qu'avec les outils actuels de suivi de code et autre Changelog,
on peut identifier a posteriori Toto Contributeur comme auteur des 10 lignes
dans le résultat final. Mais on peut aussi resssortir d'une encyclopédie qui
est celui qui a écrit tel ou tel bout d'article : cependant, il est
généralement considéré qu'une encyclopédie est une ouvre collective.

Ça marche dans les deux sens : Toto Contributeur dit à l'auteur « tu
acceptes mon patch sous _mes_ conditions, et si tu n'es pas content
tu n'as qu'à refaire le boulot toi-même. ».
Euh, non, cela je ne le prends pas.

Pas compris. Qu'est-ce que tu ne prends pas ?

Bin, en tant que contributeur je n'ai jamais vu la possibilité d'exprimer de
telles conditions... (ni la moindre condition, d'ailleurs.)
En gros, soit j'adhère intégralement à la charte ou les éléments disponibles
(qui ne constitue absolument pas un contrat), soit je n'envois pas.

En fait si, il y a bien un moyen de poser les conditions, comme je le
mentionnais auparavant : c'est de mettre _explicitement_ le patch sous GPL.
Là, c'est clair, et effectivement si l'auteur accepte le patch l'ouvre est
verrouillée sous GPL (sauf postérieure rétractation explicite de Toto).

Mais si j'ai bien compris qu'en fait tu sous-entends « je contribue
à ton logiciel que sous la promesse que tu le gardes libre », pour
moi cela ne marche pas, en tous cas je ne trouve pas cela évident
(en droit, moralement c'est autre chose).

Non, ce n'est pas ça. Ce que c'est, c'est : « Je contribue à ton
logiciel, et si tu acceptes, ça devient _notre_ logiciel. Et je te
préviens, je n'accepterai pas d'autre licence que la GPL. ».

Oui, cela c'est ton avis, mais c'est cela que je ne vois pas clairement,
sauf à le préciser explicitement.

D'abord, je fais une différence à ce niveau entre un patch qui
précise explicitement (ou implicitement au travers des conditions du
projet, un peu genre le contrat Debian) "ce patch est placé sous
GPL", et un autre qui ne le fait pas. Dans la pratique, je vois
passer les deux.

Un patch à un logiciel sous GPL par quelqu'un d'autre que le
titulaire du copyright de la partie patchée est toujours
implicitement sous GPL, puisque la licence du logiciel interdit d'en
reditstribuer des versions modifiées autrement que sous GPL, et que
le patch est précisément une version modifiée.

Non.
La diffusion par l'auteur du patch (Toto) de l'assemblage de la version
originale et de son patch est effectivement sous GPL (ce qui permet la
continuité du projet). Mais on ne parle pas de cela ici.

Parce que si ce que tu écrivais ci-dessus était correct, il serait
absolument impossible d'avoir des logiciels avec deux licences, GPL et autre
chose (disons MIT).

Par ailleurs, juridiquement « logiciel sous GPL » je ne vois pas comment
cela affecte le logiciel en tant que tel (cela affecte sa redistribution, là
on est d'accord, mais c'est autre chose).

Il est évidemment question de patches non triviaux.

Mais pour moi, la limite de 10 lignes est historiquement est une observation
empirique des auteurs de XxxBSD pour être sûr de bien englober, par excès,
toutes les contributions non triviales, ou plus exactement une manière
d'éviter de perdre du temps à considérer les patchs triviaux dans les
problèmes de droits d'auteur. Je ne trouve pas correct de l'utiliser telle
quelle pour caractériser ce qui constitue une ouvre de l'esprit.

Si tu remplaces cela par les définitions pertinentes du CPI, on serait
d'accord.

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

En news:dun6qb$23kr$, Nicolas George va escriure:

Et je ne parle pas de la diffusion de l'ouvre pour laquelle ils ont
contribué le morceau de code (qui est clairement sous GPL), mais des
autres ouvres parallèles de l'auteur original (désolé pour
l'expression malheureuse, j'espère que l'idée reste claire).

Ah bon, première nouvelle. Je croyais qu'on parlait du fait qu'un
auteur qui accepte une contribution tierce dans un code qu'il a
distribué sous GPL perd la possibilité de distribuer sous une autre
licence sans l'accord du contributeur.

Bin oui, on parle bien de la même chose.
J'essaye de comprendre pourquoi le fait que l'ouvre soit diffusée sous GPL
change le régime juridique des autres diffusions (en gros, les interdit, y
compris pour l'auteur original qui a placé l'ouvre en GPL).

Par ailleurs, j'ai du mal à imaginer l'applicabilité pratique de ce
que tu décris ; par contre, si on considère l'ouvre comme
collective, cela devient beaucoup plus facile à imaginer...

Le terme correct est oeuvre de collaboration, ce qui est différent
d'oeuvre collective. Et ça revient à ce que je dis : la diffusion
doit être autorisée par tous les auteurs.

Je sais bien que ce que tu décris s'appelle une ouvre de collaboration. Ce
que je cherche, c'est ce qui motive la qualification d'une contribution de
10 lignes comme ouvre de collaboration, et non pas comme ouvre collective,
dirigée par l'auteur, que par ailleurs tout le monde connaît et identifie
comme tel.

Je sais bien qu'avec les outils actuels de suivi de code et autre Changelog,
on peut identifier a posteriori Toto Contributeur comme auteur des 10 lignes
dans le résultat final. Mais on peut aussi resssortir d'une encyclopédie qui
est celui qui a écrit tel ou tel bout d'article : cependant, il est
généralement considéré qu'une encyclopédie est une ouvre collective.

Ça marche dans les deux sens : Toto Contributeur dit à l'auteur « tu
acceptes mon patch sous _mes_ conditions, et si tu n'es pas content
tu n'as qu'à refaire le boulot toi-même. ».
Euh, non, cela je ne le prends pas.

Pas compris. Qu'est-ce que tu ne prends pas ?

Bin, en tant que contributeur je n'ai jamais vu la possibilité d'exprimer de
telles conditions... (ni la moindre condition, d'ailleurs.)
En gros, soit j'adhère intégralement à la charte ou les éléments disponibles
(qui ne constitue absolument pas un contrat), soit je n'envois pas.

En fait si, il y a bien un moyen de poser les conditions, comme je le
mentionnais auparavant : c'est de mettre _explicitement_ le patch sous GPL.
Là, c'est clair, et effectivement si l'auteur accepte le patch l'ouvre est
verrouillée sous GPL (sauf postérieure rétractation explicite de Toto).

Mais si j'ai bien compris qu'en fait tu sous-entends « je contribue
à ton logiciel que sous la promesse que tu le gardes libre », pour
moi cela ne marche pas, en tous cas je ne trouve pas cela évident
(en droit, moralement c'est autre chose).

Non, ce n'est pas ça. Ce que c'est, c'est : « Je contribue à ton
logiciel, et si tu acceptes, ça devient _notre_ logiciel. Et je te
préviens, je n'accepterai pas d'autre licence que la GPL. ».

Oui, cela c'est ton avis, mais c'est cela que je ne vois pas clairement,
sauf à le préciser explicitement.

D'abord, je fais une différence à ce niveau entre un patch qui
précise explicitement (ou implicitement au travers des conditions du
projet, un peu genre le contrat Debian) "ce patch est placé sous
GPL", et un autre qui ne le fait pas. Dans la pratique, je vois
passer les deux.

Un patch à un logiciel sous GPL par quelqu'un d'autre que le
titulaire du copyright de la partie patchée est toujours
implicitement sous GPL, puisque la licence du logiciel interdit d'en
reditstribuer des versions modifiées autrement que sous GPL, et que
le patch est précisément une version modifiée.

Non.
La diffusion par l'auteur du patch (Toto) de l'assemblage de la version
originale et de son patch est effectivement sous GPL (ce qui permet la
continuité du projet). Mais on ne parle pas de cela ici.

Parce que si ce que tu écrivais ci-dessus était correct, il serait
absolument impossible d'avoir des logiciels avec deux licences, GPL et autre
chose (disons MIT).

Par ailleurs, juridiquement « logiciel sous GPL » je ne vois pas comment
cela affecte le logiciel en tant que tel (cela affecte sa redistribution, là
on est d'accord, mais c'est autre chose).

Il est évidemment question de patches non triviaux.

Mais pour moi, la limite de 10 lignes est historiquement est une observation
empirique des auteurs de XxxBSD pour être sûr de bien englober, par excès,
toutes les contributions non triviales, ou plus exactement une manière
d'éviter de perdre du temps à considérer les patchs triviaux dans les
problèmes de droits d'auteur. Je ne trouve pas correct de l'utiliser telle
quelle pour caractériser ce qui constitue une ouvre de l'esprit.

Si tu remplaces cela par les définitions pertinentes du CPI, on serait
d'accord.

Antoine

Antoine Leca

09/03/2006 à 17:02

En news:, Emmanuel Florac va
escriure:

Oui mais tu utilises Windows, donc tu peux crever, en l'ocurrence.

Cela s'appelle débattre ?

Parce que les gens sont extrèmement attachés à leurs habitudes,
surtout celles qui leur ont coûté.

Disons que d'accord.
Cependant, lors du passage de MS-DOS à MacOS, les habitudes avaient coûtées
(et combien), mais elles n'ont pas fait le poids.

Pour la plupart des gens, l'apprentissage des tâches windowsiennes
de base a été long et douloureux.

?
Je ne prend pas mon exemple, parce que pour moi cela a effectivement été
long et douloureux : primo ma bécane ne supportait pas la charge, et de plus
la programmation sous Windows c'est infiniment plus galère que la
programmation pour ligne de commande et mono thread.

Mais quand les machines ont eues les performances nécessaires et que Windows
lui-même est sorti de la période bogué-à-donf' (3.1, en gros), le passage
vers Windows s'est fait dans la joie et le bonheur.
Un peu comme, à peu près au même moment, sur stations de travail on est
passé de la ligne de commande (voire des JCL) aux environnements graphiques
sous X11...

un changement un tant soit peu important (comme passer de windows à
KDE) est vécu comme intolérable.

Tu es insultant pour « la plupart des gens ».

Ce n'est intolérable du tout, d'ailleurs c'est généralement très bien
supporté en définitive, en tout cas lorsqu'il y a des bénéfices
perceptibles.

C'est stressant, d'accord, mais ce n'est pas pareil.

Par ailleurs, en environnement d'entreprise, c'est souvent un changement
subi sans l'avoir voulu ni même avoir été consulté, ce qui crée (en France
surtout ;-) un mouvement de rejet.

C'est absolument indépendant de la qualité des logiciels;

En fait, absolument tout ce que tu dis est indépendant du fait que la
plateforme de départ soit Windows ou Linux ou CICS.

Par ailleurs non, à condition de considérer (cf.infra, Joel Spolski) que
l'ergonomie (tant d'utilisation comme de prise en main) du logiciel importe
pour en définir la qualité, un logiciel facile à adopter s'imposera face à
celui qui est rébarbatif, et celui qui n'apporte rien de plus ne rendra pas
la place de l'existant.

Cette force de l'habitude est si extrème que les voitures
européennes n'ont toujours pas de boîte de vitesse automatique,
alors que ça existe depuis plus de 60 ans.

... et que cela consomme 1 l/100 (au moins) soit x g de C ; et par ailleurs
que les conducteurs européens (hommes comme femmes) ont le besoin physique
de tripoter leurs leviers de vitesse.

Une illustration dans joel on software de ce principe essentiel :

Il dit à peu près exactement le contraire de toi : si les utilisateurs
rentrent comme dans un gant dans le nouveau paradigme, il n'y a aucun
problème. Adaptation que Windows (et les environnements KDE et Gnome) ont
bien proposés, progressivement, à leurs utilisateurs venant d'autres
horizons.

Un des problèmes avec l'interface Windows, c'est qu'il y a plusieurs
manières de faire quelque chose, et que l'imitateur n'imite que celle que
lui utilise, donc rate systématiquement celles qu'utilisent les autres.
(Cela attrape tout le monde, y compris ceux qui développent de nouveaux
logiciels pour Windows.) Le même problème existe dans l'autre sens
d'ailleurs, par exemple avec l'utilisation des trois boutons des souris dans
les interfaces X11.

Antoine

En news:pan.2006.03.08.21.17.59.606197@imaginet.fr, Emmanuel Florac va
escriure:

Oui mais tu utilises Windows, donc tu peux crever, en l'ocurrence.

Cela s'appelle débattre ?

Parce que les gens sont extrèmement attachés à leurs habitudes,
surtout celles qui leur ont coûté.

Disons que d'accord.
Cependant, lors du passage de MS-DOS à MacOS, les habitudes avaient coûtées
(et combien), mais elles n'ont pas fait le poids.

Pour la plupart des gens, l'apprentissage des tâches windowsiennes
de base a été long et douloureux.

?
Je ne prend pas mon exemple, parce que pour moi cela a effectivement été
long et douloureux : primo ma bécane ne supportait pas la charge, et de plus
la programmation sous Windows c'est infiniment plus galère que la
programmation pour ligne de commande et mono thread.

Mais quand les machines ont eues les performances nécessaires et que Windows
lui-même est sorti de la période bogué-à-donf' (3.1, en gros), le passage
vers Windows s'est fait dans la joie et le bonheur.
Un peu comme, à peu près au même moment, sur stations de travail on est
passé de la ligne de commande (voire des JCL) aux environnements graphiques
sous X11...

un changement un tant soit peu important (comme passer de windows à
KDE) est vécu comme intolérable.

Tu es insultant pour « la plupart des gens ».

Ce n'est intolérable du tout, d'ailleurs c'est généralement très bien
supporté en définitive, en tout cas lorsqu'il y a des bénéfices
perceptibles.

C'est stressant, d'accord, mais ce n'est pas pareil.

Par ailleurs, en environnement d'entreprise, c'est souvent un changement
subi sans l'avoir voulu ni même avoir été consulté, ce qui crée (en France
surtout ;-) un mouvement de rejet.

C'est absolument indépendant de la qualité des logiciels;

En fait, absolument tout ce que tu dis est indépendant du fait que la
plateforme de départ soit Windows ou Linux ou CICS.

Par ailleurs non, à condition de considérer (cf.infra, Joel Spolski) que
l'ergonomie (tant d'utilisation comme de prise en main) du logiciel importe
pour en définir la qualité, un logiciel facile à adopter s'imposera face à
celui qui est rébarbatif, et celui qui n'apporte rien de plus ne rendra pas
la place de l'existant.

Cette force de l'habitude est si extrème que les voitures
européennes n'ont toujours pas de boîte de vitesse automatique,
alors que ça existe depuis plus de 60 ans.

... et que cela consomme 1 l/100 (au moins) soit x g de C ; et par ailleurs
que les conducteurs européens (hommes comme femmes) ont le besoin physique
de tripoter leurs leviers de vitesse.

Une illustration dans joel on software de ce principe essentiel :

Il dit à peu près exactement le contraire de toi : si les utilisateurs
rentrent comme dans un gant dans le nouveau paradigme, il n'y a aucun
problème. Adaptation que Windows (et les environnements KDE et Gnome) ont
bien proposés, progressivement, à leurs utilisateurs venant d'autres
horizons.

Un des problèmes avec l'interface Windows, c'est qu'il y a plusieurs
manières de faire quelque chose, et que l'imitateur n'imite que celle que
lui utilise, donc rate systématiquement celles qu'utilisent les autres.
(Cela attrape tout le monde, y compris ceux qui développent de nouveaux
logiciels pour Windows.) Le même problème existe dans l'autre sens
d'ailleurs, par exemple avec l'utilisation des trois boutons des souris dans
les interfaces X11.

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

En news:, Emmanuel Florac va
escriure:

Oui mais tu utilises Windows, donc tu peux crever, en l'ocurrence.

Cela s'appelle débattre ?

Parce que les gens sont extrèmement attachés à leurs habitudes,
surtout celles qui leur ont coûté.

Disons que d'accord.
Cependant, lors du passage de MS-DOS à MacOS, les habitudes avaient coûtées
(et combien), mais elles n'ont pas fait le poids.

Pour la plupart des gens, l'apprentissage des tâches windowsiennes
de base a été long et douloureux.

?
Je ne prend pas mon exemple, parce que pour moi cela a effectivement été
long et douloureux : primo ma bécane ne supportait pas la charge, et de plus
la programmation sous Windows c'est infiniment plus galère que la
programmation pour ligne de commande et mono thread.

Mais quand les machines ont eues les performances nécessaires et que Windows
lui-même est sorti de la période bogué-à-donf' (3.1, en gros), le passage
vers Windows s'est fait dans la joie et le bonheur.
Un peu comme, à peu près au même moment, sur stations de travail on est
passé de la ligne de commande (voire des JCL) aux environnements graphiques
sous X11...

un changement un tant soit peu important (comme passer de windows à
KDE) est vécu comme intolérable.

Tu es insultant pour « la plupart des gens ».

Ce n'est intolérable du tout, d'ailleurs c'est généralement très bien
supporté en définitive, en tout cas lorsqu'il y a des bénéfices
perceptibles.

C'est stressant, d'accord, mais ce n'est pas pareil.

Par ailleurs, en environnement d'entreprise, c'est souvent un changement
subi sans l'avoir voulu ni même avoir été consulté, ce qui crée (en France
surtout ;-) un mouvement de rejet.

C'est absolument indépendant de la qualité des logiciels;

En fait, absolument tout ce que tu dis est indépendant du fait que la
plateforme de départ soit Windows ou Linux ou CICS.

Par ailleurs non, à condition de considérer (cf.infra, Joel Spolski) que
l'ergonomie (tant d'utilisation comme de prise en main) du logiciel importe
pour en définir la qualité, un logiciel facile à adopter s'imposera face à
celui qui est rébarbatif, et celui qui n'apporte rien de plus ne rendra pas
la place de l'existant.

Cette force de l'habitude est si extrème que les voitures
européennes n'ont toujours pas de boîte de vitesse automatique,
alors que ça existe depuis plus de 60 ans.

... et que cela consomme 1 l/100 (au moins) soit x g de C ; et par ailleurs
que les conducteurs européens (hommes comme femmes) ont le besoin physique
de tripoter leurs leviers de vitesse.

Une illustration dans joel on software de ce principe essentiel :

Il dit à peu près exactement le contraire de toi : si les utilisateurs
rentrent comme dans un gant dans le nouveau paradigme, il n'y a aucun
problème. Adaptation que Windows (et les environnements KDE et Gnome) ont
bien proposés, progressivement, à leurs utilisateurs venant d'autres
horizons.

Un des problèmes avec l'interface Windows, c'est qu'il y a plusieurs
manières de faire quelque chose, et que l'imitateur n'imite que celle que
lui utilise, donc rate systématiquement celles qu'utilisent les autres.
(Cela attrape tout le monde, y compris ceux qui développent de nouveaux
logiciels pour Windows.) Le même problème existe dans l'autre sens
d'ailleurs, par exemple avec l'utilisation des trois boutons des souris dans
les interfaces X11.

Antoine

Antoine Leca

09/03/2006 à 17:05

En news:440f5717$0$7670$,
Stéphane CARPENTIER va escriure:

En gros tu t'en prends plein la gueule pour pas un rond et tu
n'as que l'option de te la fermer. Autrement dit estime-toi
heureux de ne pas avoir été là sur le coup.

C'est exactement ce qu'il a écrit.

Pas exactement. Lui voyait l'impact sur sa carrière. Je peux te dire qu'il
n'y a pas que ta carrière qui peut ressortir touchée.

Antoine

Nicolas George

09/03/2006 à 17:09

"Antoine Leca" , dans le message <dupith$jrl$, a
écrit :

Bin, en tant que contributeur je n'ai jamais vu la possibilité d'exprimer de
telles conditions... (ni la moindre condition, d'ailleurs.)

Qu'est-ce que tu voudrais, comme « possibilité » ?

En gros, soit j'adhère intégralement à la charte ou les éléments disponibles
(qui ne constitue absolument pas un contrat), soit je n'envois pas.

Qui t'impose cette alternative ? Personne. Tu peux tout à fait proposer ton
patch en indiquant tes conditions. Si ton patch a de la valeur, tu es en
position de négocier. Évidemment, si ton patch est sans intérêt ou facile à
paraphraser, ça se passe moins bien. C'est une question de rapport de force.

Ce sur quoi tu peux compter, c'est qu'on incorpore ton patch sans se soucier
des questions légales, et qu'on continue à développer le logiciel, au point
de diluer le patch et le rendre indissociable du reste du code. Tu te
retrouves alors en position de force.

Là, c'est clair, et effectivement si l'auteur accepte le patch l'ouvre est
verrouillée sous GPL (sauf postérieure rétractation explicite de Toto).

Précisément. C'est exactement de ça que je parlais. Sauf qu'il n'est pas
nécessaire que le patch soit explicitement sous GPL si ce sur quoi il
s'applique est soi-même sous GPL.

Non.
La diffusion par l'auteur du patch (Toto) de l'assemblage de la version
originale et de son patch est effectivement sous GPL (ce qui permet la
continuité du projet). Mais on ne parle pas de cela ici.

Le patch contient des parties du code original, ne serait-ce que les
quelques lignes de contexte. Si le code original a été obtenu sous GPL,
alors le patch est forcément sous GPL. C'est inévitable.

Parce que si ce que tu écrivais ci-dessus était correct, il serait
absolument impossible d'avoir des logiciels avec deux licences, GPL et autre
chose (disons MIT).

Si : il suffit que tous les contributeurs soient d'accord. Ce qui peut en
particulier être le cas si aucune contribution extérieure n'est acceptée
sans ré-écriture complète.

"Antoine Leca" , dans le message <dupith$jrl$1@shakotay.alphanet.ch>, a
écrit :

Bin, en tant que contributeur je n'ai jamais vu la possibilité d'exprimer de
telles conditions... (ni la moindre condition, d'ailleurs.)

Qu'est-ce que tu voudrais, comme « possibilité » ?

En gros, soit j'adhère intégralement à la charte ou les éléments disponibles
(qui ne constitue absolument pas un contrat), soit je n'envois pas.

Qui t'impose cette alternative ? Personne. Tu peux tout à fait proposer ton
patch en indiquant tes conditions. Si ton patch a de la valeur, tu es en
position de négocier. Évidemment, si ton patch est sans intérêt ou facile à
paraphraser, ça se passe moins bien. C'est une question de rapport de force.

Ce sur quoi tu peux compter, c'est qu'on incorpore ton patch sans se soucier
des questions légales, et qu'on continue à développer le logiciel, au point
de diluer le patch et le rendre indissociable du reste du code. Tu te
retrouves alors en position de force.

Là, c'est clair, et effectivement si l'auteur accepte le patch l'ouvre est
verrouillée sous GPL (sauf postérieure rétractation explicite de Toto).

Précisément. C'est exactement de ça que je parlais. Sauf qu'il n'est pas
nécessaire que le patch soit explicitement sous GPL si ce sur quoi il
s'applique est soi-même sous GPL.

Non.
La diffusion par l'auteur du patch (Toto) de l'assemblage de la version
originale et de son patch est effectivement sous GPL (ce qui permet la
continuité du projet). Mais on ne parle pas de cela ici.

Le patch contient des parties du code original, ne serait-ce que les
quelques lignes de contexte. Si le code original a été obtenu sous GPL,
alors le patch est forcément sous GPL. C'est inévitable.

Parce que si ce que tu écrivais ci-dessus était correct, il serait
absolument impossible d'avoir des logiciels avec deux licences, GPL et autre
chose (disons MIT).

Si : il suffit que tous les contributeurs soient d'accord. Ce qui peut en
particulier être le cas si aucune contribution extérieure n'est acceptée
sans ré-écriture complète.

Vous avez filtré cet utilisateur ! Consultez son message

"Antoine Leca" , dans le message <dupith$jrl$, a
écrit :

Bin, en tant que contributeur je n'ai jamais vu la possibilité d'exprimer de
telles conditions... (ni la moindre condition, d'ailleurs.)

Qu'est-ce que tu voudrais, comme « possibilité » ?

En gros, soit j'adhère intégralement à la charte ou les éléments disponibles
(qui ne constitue absolument pas un contrat), soit je n'envois pas.

Qui t'impose cette alternative ? Personne. Tu peux tout à fait proposer ton
patch en indiquant tes conditions. Si ton patch a de la valeur, tu es en
position de négocier. Évidemment, si ton patch est sans intérêt ou facile à
paraphraser, ça se passe moins bien. C'est une question de rapport de force.

Ce sur quoi tu peux compter, c'est qu'on incorpore ton patch sans se soucier
des questions légales, et qu'on continue à développer le logiciel, au point
de diluer le patch et le rendre indissociable du reste du code. Tu te
retrouves alors en position de force.

Là, c'est clair, et effectivement si l'auteur accepte le patch l'ouvre est
verrouillée sous GPL (sauf postérieure rétractation explicite de Toto).

Précisément. C'est exactement de ça que je parlais. Sauf qu'il n'est pas
nécessaire que le patch soit explicitement sous GPL si ce sur quoi il
s'applique est soi-même sous GPL.

Non.
La diffusion par l'auteur du patch (Toto) de l'assemblage de la version
originale et de son patch est effectivement sous GPL (ce qui permet la
continuité du projet). Mais on ne parle pas de cela ici.

Le patch contient des parties du code original, ne serait-ce que les
quelques lignes de contexte. Si le code original a été obtenu sous GPL,
alors le patch est forcément sous GPL. C'est inévitable.

Parce que si ce que tu écrivais ci-dessus était correct, il serait
absolument impossible d'avoir des logiciels avec deux licences, GPL et autre
chose (disons MIT).

Si : il suffit que tous les contributeurs soient d'accord. Ce qui peut en
particulier être le cas si aucune contribution extérieure n'est acceptée
sans ré-écriture complète.

Jerome Lambert

09/03/2006 à 17:30

En news:, Emmanuel Florac va
escriure:
(...)

un changement un tant soit peu important (comme passer de windows à
KDE) est vécu comme intolérable.

Tu es insultant pour « la plupart des gens ».

Malheureusement non. Il est au contraire très réaliste. Même des
changements relativement mineurs tels que passer de l'interface de
Windows 2000 à celle de XP (avec p.ex. la disparition de l'icône du
poste de travail) engendrent des grognements chez "la plupart des gens",
ce qui fait que peu d'entre eux ont l'ouverture d'esprit pour ne fut-ce
qu'essayer des alternatives, histoire de se faire une idée.
Combien de fois ai-je entendu "non merci, je suis habitué à Windows, ça
me convient comme ça"...

(...)

Par ailleurs, en environnement d'entreprise, c'est souvent un changement
subi sans l'avoir voulu ni même avoir été consulté, ce qui crée (en France
surtout ;-) un mouvement de rejet.

Sauf qu'en entreprise, la "motivation" n'est pas vraiment la même... ;-)

(...)

Une illustration dans joel on software de ce principe essentiel :

Il dit à peu près exactement le contraire de toi : si les utilisateurs
rentrent comme dans un gant dans le nouveau paradigme, il n'y a aucun
problème. Adaptation que Windows (et les environnements KDE et Gnome) ont
bien proposés, progressivement, à leurs utilisateurs venant d'autres
horizons.

Un des problèmes avec l'interface Windows, c'est qu'il y a plusieurs
manières de faire quelque chose, et que l'imitateur n'imite que celle que
lui utilise, donc rate systématiquement celles qu'utilisent les autres.
(Cela attrape tout le monde, y compris ceux qui développent de nouveaux
logiciels pour Windows.) Le même problème existe dans l'autre sens
d'ailleurs, par exemple avec l'utilisation des trois boutons des souris dans
les interfaces X11.

Et comme l'illustre justement l'article, ce ne sont pas les similitudes
qui sauteront aux yeux, mais au contraire les quelques subtiles
différences, et ces différences engendredront un sentiment de rejet.

En news:pan.2006.03.08.21.17.59.606197@imaginet.fr, Emmanuel Florac va
escriure:
(...)

un changement un tant soit peu important (comme passer de windows à
KDE) est vécu comme intolérable.

Tu es insultant pour « la plupart des gens ».

Malheureusement non. Il est au contraire très réaliste. Même des
changements relativement mineurs tels que passer de l'interface de
Windows 2000 à celle de XP (avec p.ex. la disparition de l'icône du
poste de travail) engendrent des grognements chez "la plupart des gens",
ce qui fait que peu d'entre eux ont l'ouverture d'esprit pour ne fut-ce
qu'essayer des alternatives, histoire de se faire une idée.
Combien de fois ai-je entendu "non merci, je suis habitué à Windows, ça
me convient comme ça"...

(...)

Par ailleurs, en environnement d'entreprise, c'est souvent un changement
subi sans l'avoir voulu ni même avoir été consulté, ce qui crée (en France
surtout ;-) un mouvement de rejet.

Sauf qu'en entreprise, la "motivation" n'est pas vraiment la même... ;-)

(...)

Une illustration dans joel on software de ce principe essentiel :

Il dit à peu près exactement le contraire de toi : si les utilisateurs
rentrent comme dans un gant dans le nouveau paradigme, il n'y a aucun
problème. Adaptation que Windows (et les environnements KDE et Gnome) ont
bien proposés, progressivement, à leurs utilisateurs venant d'autres
horizons.

Un des problèmes avec l'interface Windows, c'est qu'il y a plusieurs
manières de faire quelque chose, et que l'imitateur n'imite que celle que
lui utilise, donc rate systématiquement celles qu'utilisent les autres.
(Cela attrape tout le monde, y compris ceux qui développent de nouveaux
logiciels pour Windows.) Le même problème existe dans l'autre sens
d'ailleurs, par exemple avec l'utilisation des trois boutons des souris dans
les interfaces X11.

Et comme l'illustre justement l'article, ce ne sont pas les similitudes
qui sauteront aux yeux, mais au contraire les quelques subtiles
différences, et ces différences engendredront un sentiment de rejet.

Vous avez filtré cet utilisateur ! Consultez son message

talon

09/03/2006 à 17:56

Jerome Lambert wrote:

Combien de fois ai-je entendu "non merci, je suis habitué à Windows, ça
me convient comme ça"...

Sans parler du fait que dans l'exemple que j'ai cité, il s'agit d'étudiants en
Licence, donc jeunes, formés à diverses choses, ayant déjà utilisé Linux dans
leur enseignement, venant de passer 15 jours sous un système libre, sous KDE,
ayant utilisé sans problème toutes sortes d'outils dans cet environnement,
dont Kile, Latex, gv, maple, xfig, etc. pour faire leur business, et
d'ailleurs fort contents du résultat. Or à la fin le résultat est exactement
le même "je suis habitué à Windows". Je ne crois pas être parano en disant que
ce qu'ils pensent dans leur for intérieur, c'est "Linux, c'est un truc pour
ces cons d'enseignants, qui perdent leur temps à faire des trucs débiles,
et on ne va sûrement pas faire pareil".

--

Michel TALON

Un truc qui me tracasse sur le libre.

10 réponses

Veuillez sélectionner un problème