Linux: une perte de temps ?

[Herve Eychenne]

Lu sur slashdot:
"Un article du Chicago Tribune suggère que la somme d'efforts
déployés pour Linux serait mieux rentablilisée (en terme de temps)
en contribuant à l'amélioration des logiciels Microsoft.
L'auteur souligne que Linux est entrain de réinventer la roue.
Linux n'est-il pas une perte de temps ?"

Argument qu'il m'a déjà été donné d'entendre, notamment dans la bouche
d'un des mes compagnons ENSERBien (j'ai honte).
Ma réponse avait à l'époque été en substance celle-ci:
"Ils ont été trop loin. Même si Microsoft délivrait une grande
partie de son code source, cela ne changerait rien.
Pas un de leurs systèmes d'exploitation successifs n'a jamais valu le
moindre centime.
Ils sont trop mauvais sur le plan technique, et trop dangereux sur le
plan éthique. Ils ont sali pour longtemps la belle conception que l'on
peut se faire de l'informatique. Il faut les abattre définitivement."

A l'époque, j'étais encore jeune. ;-) Maintenant que je suis convaincu
que le logiciel libre a un avenir radieux, je suis moins véhément.
Je sais que la fin du monopole de Microsoft s'amorce.

Pour en revenir plus directement à la question posée, je suis sûr qu'il
y a matière à discuter sur le sujet:
En ce qui concerne Microsoft, tout d'abord:
- Microsoft n'a jamais rien inventé. S'il en est qui ont passé leur temps
à copier les techniques existantes, puis à essayer de faire croire à de
prétendues nouvelles inventions, c'est bien eux;
- il est moins que certain que le fait de mettre son talent
bénévolement au service d'une firme aussi mercantile que Microsoft
entousiasme les développeurs de Linux;

Pour ce qui est du logiciel libre:
- le foisonnement d'idées apportées par chacun est une source de richesse
et de diversité inestimable;
- le temps n'est pas la préoccupation principale. C'est la qualité du
produit fini qui compte.
- l'un des principes fondateurs de la GPL est de favoriser la
réutilisation de code existant, afin de racourcir les temps de
développement et de limiter le renouvellement des erreurs passées.

Cependant, la question de la perte de temps dans le modèle de
développement libre me semble bien réelle:
- si la réutilisation de code était massive, une erreur détectée dans
un code source pourrait très bien s'être largement propagée, et serait
difficile à corriger dans tous les logiciels ayant repris cette
partie de code;
- le développement du logiciel libre est assez anarchique. S'il est vrai
que tout système tend à s'auto-organiser, il n'empêche que l'entropie
augmente. Trop de programmeurs semblent se lancer dans un projet sans
prendre la peine de se renseigner pour savoir ce qui a été effectué
auparavant sur le sujet;
- le logiciel libre n'a pas empêché le développement de deux bureaux
comparables tels que Gnome et KDE, quelles qu'en soient les causes.
Sans compter la duplication de toutes les G_applications et
K_applications correspondantes. Que l'on soit pour l'un ou pour
l'autre, on ne peut s'empêcher de penser à un beau gâchis et à tout le
temps perdu.
A la limite, certains pourraient parler de la concurrence
Linux/FreeBSD. Mais ce serait sans doute une erreur: les problèmes
de la licence BSD sont suffisamment importants aux yeux de certains
pour justifier un développement parallèle;
- le polymophisme des applications est une force, mais constitue trop
souvent un frein, devant l'accumulation de cas particuliers dans la
forme, mais redondants sur le fond;
- chacun refait tout de même un peu les mêmes choses dans son coin.
Par exemple, il est regrettable que les différentes distributions de
Linux améliorent leurs procédures d'installation en parallèle, sans
que les uns bénéficient directement des avancées des autres.
Si chacun s'était entendu sur un standard commun (de nivellement par
le haut, cela va de soi), que d'efforts auraient été épargnés...

Des efforts de standardisation tels que le LSB sont à mon avis plus que
jamais nécessaires.

On assiste donc à une pseudo organisation de type fourmilière, où
l'ensemble de l'ouvrage finit tout de même par prendre forme, mais
au prix d'un déploiement d'énergie trop souvent gaspillée.

Il est donc capital de fournir des modèles réutilisables, à tous les
niveaux possibles. Ainsi, toute application devrait être conçue de bas
en haut. A savoir: fournir une bibliothèque de fonctions non
interactives, au-dessus de laquelle seraient bâties les interfaces
texte et graphique, avec un dialogue entre les deux niveaux, selon un
protocole bien défini. A l'extrême, il serait ainsi possible
d'intervenir dans une application graphique au moyen d'un simple
script shell, par exemple.
De même, la configuration d'une application devrait pouvoir se faire
tant en mode texte, en éditant un fichier de configuration
intelligible, qu'en mode graphique, par l'intermédiaire d'une
application qui lirait ce même fichier de configuration et le
modifierait, sans écraser les modifications faites à la main comme on
le voit trop souvent !

Dans le même ordre d'idée, quel bonheur si les applications de même
type fournissaient une interface standardisée (au niveau logiciel),
à la manière du VFS (Virtual File System) pour les systèmes de fichiers,
qui permettrait une modularité quasi-infinie.
Par exemple, il deviendrait ainsi possible de commander le déplacement
d'un fenêtre de manière non-interactive, ou de la changer d'écran
virtuel d'une façon unique, sans ce soucier de savoir s'il on utilise
AfterStep, WindowMaker, Fvwm, ou tout autre gestionnaire de fenêtre.

S'il est vrai que le modèle "Bazar" possède de grandes forces,
l'absence d'un architecte garantissant une cohérence d'ensemble se
fait parfois cruellement sentir.

Le défi crucial est la modularité, ce qui suppose de s'entendre sur
une interface respectée par chacun. L'histoire prouve que jusqu'à
présent, le souci de modularité n'a pas été assez poussé, du moins au
niveau des applications. Soit. Il fallait bien un début.
Mais maintenant que la machine est lancée, il faudrait imprimer une
cohérence, des articulations communes.
L'initiative ne peut venir à mon sens que d'une volonté extérieure à
chacune des équipes de développement, qui après avoir obtenu l'accord
de tous, doit s'entendre avec elle pour définir un standard qui serait
au moins un plus petit commun multiple des différentes fonctionnalités
offertes.

Ainsi, outre une facilité d'utilisation grandement accrue, cela
permettrait à chacun de réinventer un peu moins la roue dans son coin,
et de s'inscrire immédiatement dans un cadre cohérent.

RV

P.S.: désolé pour la longueur excessive de ce post. Bravo à ceux qui
ont tenu jusqu'ici.

--
_
(°= Hervé EYCHENNE : eych...@info.enserb.u-bordeaux.fr
//) E.N.S.E.R.B. : http://www.enserb.u-bordeaux.fr/~eychenne
v_/_
UNIX n'a pas été conçu de façon à empêcher les utilisateurs de faire
des choses stupides afin d'éviter de leur refuser du même coup les
actions élégantes. -- Doug Gwyn

[emmanue...@skynet.be]

On 26 Apr 1999 03:49:26 GMT, Herve Eychenne
<eych...@info.enserb.u-bordeaux.fr> wrote:

[trop long, même si c'était intéressant, pour tout reprendre]

Je pense que le moyen le plus efficace pour avoir une certaine
cohérence, et surtout une bonne modularité parmi toutes les applis
libres est de s'attacher à respecter des standards reconnus. Et
notamment CORBA qui peut résoudre, AMHA de profane car je ne l'ai que
survolé, beaucoup de problème de réutilisation du code vu qu'il n'est
pas tributaire d'un langage. A ce titre Gnome (et aussi KDE non ?!) me
paraît être prometteur.
D'un autre côté le foisonnement de solutions diverses et variées est
en-soi une perte de temps à priori, mais de cette diversité naissent
des solutions nouvelles peut-être plus mûres car ayant bénéficiées des
expériences précédentes. Par exemple GGI/Berlin semblent réinventer la
roue, mais peut-être pour fournir une base bien plus souple à
l'avenir? (j'espère que ceux qui en savent un peu plus long que moi
sur ce projet me corrigeront :)

Pour ce qui est des distributions, LSB et FHS me paraissent aller dans
le bon sens (mais à quelle vitesse ?), encore faut-il qu'elles le
respectent toutes (qu'en-est-il actuellement ?).

Manu

[HugoMartine]

Le 26 Apr 1999 03:49:26 GMT, Herve Eychenne
<eych...@info.enserb.u-bordeaux.fr> a écrit:

[snip]

>De même, la configuration d'une application devrait pouvoir se faire
>tant en mode texte, en éditant un fichier de configuration
>intelligible, qu'en mode graphique, par l'intermédiaire d'une
>application qui lirait ce même fichier de configuration et le
>modifierait, sans écraser les modifications faites à la main comme on
>le voit trop souvent !

Et quel bonheur cela serait pour les pauvres Newbies windowsiens de
jouer du clickdrome tout en voyant (et donc en apprenant) quels fichiers
de config sont modifiés et comment ils sont modifiés...

[snip]

>P.S.: désolé pour la longueur excessive de ce post. Bravo à ceux qui
> ont tenu jusqu'ici.

Y'a des posts bien plus courts qui sont bien plus bêtes...
--
Hugolino, le normand pas Net
"On a droit au retour de Youpla et de SpaceWalker en un seul
Meta-blaireaux. Attention les gars, lancez les kill-files, celui-la,
c'est un dangereux." (ST in "Comment moucher un merdeux, leçon n°1")

[Emmanuel Fleury]

Salut,

La première question que je me poserai devant une telle affirmation
c'est : qu'est-ce que perdre du temps?

Est-ce une perte de temps que d'abolir l'esclavage au profit des droits
de l'homme? Est-ce une perte de temps que de vouloir développer les
énergies propres face aux énergies polluantes? Pourtant, regardez
l'énergie dépensée, le nombre de vies humaines qui ont été sacrifiées
pour la première, la quantité d'argent pour la deuxième. Alors que
l'esclavage et les énergies fossiles pouvaient apporter du profit
immédiat.

Réecrire du code ne revient pas à réinventer la roue, mais à inventer
une nouvelle économie, une nouvelle culture. Au-dela du code, lorsqu'on
écrit un programme GPL qui existait déjà sous licence fermée, on apporte
une pierre à la création de l'édifice d'une économie basée dur les
logiciels ouverts.

Et si ça c'est une perte de temps, alors c'est que Microsoft est la
seule solution à nos problèmes... :-(

Bien que les considérations sur la qualités entrent elles aussi en jeux,
elles ne sont que mineures par rapport au gain que peuvent apporter les
logiciels ouverts.

* Une plus grande considération de l'utilisateur (plus de droits, plus
de pouvoirs sur le code).

* Une coopération rendue plus facile et même indispensable pour la
survie et le maintient d'un produit (donner des sources rendues
illisibles volontairement revient à se suicider dans le monde des
logiciels ouverts).

* Une préferrence est données à l'individu par rapport aux entreprises.
L'impersonnel Microsoft Windows (qui possède pourtant un chef de projet)
fait place à Emacs développé par Stallman, Linux développé par Linus,
...

* Le culte de l'argent facile et abondant est remplacé par une
valorisation du travail bien fait et de la réputation. Le modèle du
richissime Bill Gates fais moins réver que celui de Linus ou Stallman,
qui ont de quoi vivre mais sans plus.

Ce sont des améliorations dans le sens où l'individu est plus valorisé
et où le gain, en temps, en argent, en liberté est plus fort à long
terme que si on renforçait le monopole de Microsoft en l'aidant à coder.

Herve Eychenne wrote:
>
> Pour en revenir plus directement à la question posée, je suis sûr qu'il
> y a matière à discuter sur le sujet:
> En ce qui concerne Microsoft, tout d'abord:
> - Microsoft n'a jamais rien inventé. S'il en est qui ont passé leur temps
> à copier les techniques existantes, puis à essayer de faire croire à de
> prétendues nouvelles inventions, c'est bien eux;
> - il est moins que certain que le fait de mettre son talent
> bénévolement au service d'une firme aussi mercantile que Microsoft
> entousiasme les développeurs de Linux;
>
> Pour ce qui est du logiciel libre:
> - le foisonnement d'idées apportées par chacun est une source de richesse
> et de diversité inestimable;
> - le temps n'est pas la préoccupation principale. C'est la qualité du
> produit fini qui compte.
> - l'un des principes fondateurs de la GPL est de favoriser la
> réutilisation de code existant, afin de racourcir les temps de
> développement et de limiter le renouvellement des erreurs passées.

Tu compares ici deux méthodes de dévelopements et deux économies
différentes. Elles sont actuellement en concurrence sur la marché des
serveurs (et peut-être plus dans un futur proche). Linux "affronte"
Windows NT. Force est de reconnaitre que les développements de Linux
sont plus fulgurants, plus efficaces que ceux de NT (on attend toujours
NT 5.0). Force est de constater que sur beaucoup de marchés les
logiciels libres commencent à se réveler une solution viable (Apache
bien avant Linusx était une solution acceptée par des entreprises
privées).

Ce n'est un secret pour personne que de dire que les logiciels libres
gagnent du terrain. En fait, ils conquièrent le terrain d'une nouvelle
économie. Tout cela est encore en pleine expansion, mais cela se
stabilisera un jour.

Personnellement, je ne pense pas comme les extrémistes que le marché du
logiciel sera complétement recouvert par les logiciels libres (et même
ouverts). Je crois qu'un certain équilibre s'instaurera entre les deux
économies et que cet équilibre intégrera des logiciels ouverts et des
logiciels fermés.

Les logiciels libres formeront un noyau fortement réutilisé par d'autres
logiciels (compilateur, OS, bibliothèque de fonctions courantes,
environnement graphique, ...). Les logiciels ouverts mais pas libres
s'occuperont certainement des applications critiques (cryptographie,
formats de documents, ...). Les logiciels fermés eux se partageront les
applications de fin de chaîne (jeux, suites bureautiques, navigateur
web, ...).

> Cependant, la question de la perte de temps dans le modèle de
> développement libre me semble bien réelle:

Exactement. En fait je crois que cela est dû à un changement d'échelle
de la communauté concernée par ce concept. Il va falloir évoluer,
changer, se battre même parfois...

> - si la réutilisation de code était massive, une erreur détectée dans
> un code source pourrait très bien s'être largement propagée, et serait
> difficile à corriger dans tous les logiciels ayant repris cette
> partie de code;

En partie faux. La plupart des logiciels lorsqu'ils sont souvent
utilisés par d'autres se transforment en bibliothèque qui permet
d'inclure de façon dynamique le code dans les autres applications. Dès
lors, la correction d'un bug sur la bibliothèque élimine le problème
d'un coup sur toutes les applications d'un coup.

L'exemple le plus flagrant et celui de Gimp qui à ses débuts incluait sa
propre bibliothèque graphique à ses sources et qui a finalement
développé Gtk de façon indépendante pour permettre à d'autres
applications de l'utiliser. Ici aussi, éviter de réinventer la roue est
un problème que rencontrent souvent les développeurs. Elle est loin
l'époque où chaque application gérait à sa manière la souris et les
menus. :-)

> - le développement du logiciel libre est assez anarchique. S'il est vrai
> que tout système tend à s'auto-organiser, il n'empêche que l'entropie
> augmente. Trop de programmeurs semblent se lancer dans un projet sans
> prendre la peine de se renseigner pour savoir ce qui a été effectué
> auparavant sur le sujet;

Ici tu soulèves un réel problème actuel du développement des logiciels
libres. À l'heure actuelle trop de gens (pas forcément très compétent)
tendent à vouloir à tout prix participer à un projet et plutôt que de
faire un travail et de fournir du code, font des discussions oiseuses
sur les mailing-list de développement en empêchant les autres de
travailler (voir La cathédrale, le bazar et le conseil municipal sur
http://www.linux-france.com/article/these/index.html).

Tout cela vient surtout du fait que la population des gens qui
participent aux logiciels libres est d'une part trop importante pour que
l'on puisse continuer à utiliser les mêmes modes de fonctionnement
qu'avant et d'autre part vient d'une culture complétement différente de
la culture Unix (la culture Microsoft).

Il va falloir changer, et avoir une vision lucide sur ce qui faisait que
cela marchait avant pour pouvoir l'adapter à ce qui va arriver dans
notre futur proche. Par exemple reconnaitre le fait que Linux a besoin
de simple utilisateurs serait un premier pas. :-)

> - le logiciel libre n'a pas empêché le développement de deux bureaux
> comparables tels que Gnome et KDE, quelles qu'en soient les causes.
> Sans compter la duplication de toutes les G_applications et
> K_applications correspondantes. Que l'on soit pour l'un ou pour
> l'autre, on ne peut s'empêcher de penser à un beau gâchis et à tout le
> temps perdu.
> A la limite, certains pourraient parler de la concurrence
> Linux/FreeBSD. Mais ce serait sans doute une erreur: les problèmes
> de la licence BSD sont suffisamment importants aux yeux de certains
> pour justifier un développement parallèle;

Encore une fois, le temps "perdu" est un faux argument. Tout cela repose
encore sur une lutte entre logiciels libres et logiciels ouverts. Le
conflit repose essentiellement sur la licence de Qt. Malgres tout tu as
raison, il existait un projet de développement d'une bibliothèque libre
de remplacement à Qt (Harmony). Pourquoi alors vouloir tout refaire du
début?

Tout simplement parcequ'entre une bibliothèque déjà installée et une
nouvelle, la bibliothèque déjà installé l'aurait emporté sans laisser
aucune chance à l'autre. Pour le coup, c'est le travail investit dans
Harmony qui fut une perte de temps. Il fallait un bureau radicalement
différent qui reflète une appartenance aux logiciels libres et c'est que
propose Gnome.

> - le polymophisme des applications est une force, mais constitue trop
> souvent un frein, devant l'accumulation de cas particuliers dans la
> forme, mais redondants sur le fond;

Oui et non. Encore une fois, je te le rappelle, c'est l'individu que
cherche à favoriser la culture des logiciels ouverts. Permettre de
choisir parmi un grand nombre de logiciels différents celui qui nous
servira (même s'ils font la même chose) est un atout pour les individus
et donc un gain de temps considérable pour chacun (cela lui évite
d'avoir à développer ou modifier LE logiciel standard).

> - chacun refait tout de même un peu les mêmes choses dans son coin.
> Par exemple, il est regrettable que les différentes distributions de
> Linux améliorent leurs procédures d'installation en parallèle, sans
> que les uns bénéficient directement des avancées des autres.
> Si chacun s'était entendu sur un standard commun (de nivellement par
> le haut, cela va de soi), que d'efforts auraient été épargnés...
>
> Des efforts de standardisation tels que le LSB sont à mon avis plus que
> jamais nécessaires.

Là tu as raison. Mais en fait, il s'agit là d'un effort constant en
informatique. Peu à peu on pousse sous le tapis ce qui est communément
accepté par tous. Programmer en assembleur était encore il y a quelques
années une nécessité. Aujourd'hui c'est devenu impossible et de toute
façon les compilateurs sont tellement optimisé que cela ne servirai à
rien.

De la même façon, on ne reprogramme plus la gestion de la souris ou
celle des menus pour chaque application. On utilise des bibliothèques
graphiques qui font tout ça. Bref, peu à peu, on standradise, on
réutilise, on accumule une base.

Continuer cet effort me parait indispensable. L'encourager aussi. Mais
prenez garde à la standardisation galopante. Vouloir imposer un standard
qui n'en est pas un (i.e. qui n'est aps reconnu par tous) et le rendre
inamovible avant l'heure est extrèmement risqué (le triste exemple d'ATM
est là pour nous le montrer). Modération et prudence sont donc de
rigueur.

> On assiste donc à une pseudo organisation de type fourmilière, où
> l'ensemble de l'ouvrage finit tout de même par prendre forme, mais
> au prix d'un déploiement d'énergie trop souvent gaspillée.

Il existe une loi plus ou moins empirique sur la conception d'un
logiciel en équipe qui dit que l'effort pour coordonner les participants
à un projet informatique (ou pas) augmente en n^2 avec n=le nombre des
participants.

Le corrolaire de cette loi est qu'un logiciel comme Linux n'aurait
jamais dû voir le jour.

Et pourtant....

En fait, l'énergie "gaspillée" est là pour maintenir une cohésion entre
les différents programmeurs. Le reste (mode de développement, l'esprit
du programme, etc) reste cohérent grâce à l'assimilation et à l'adhésion
par tous les codeurs à la culture des logiciels ouverts. Il s'agit là
d'une sorte de canal invisible qui permet d'empêcher le projet de partir
dans tous les sens.

Donc au final, cette énergie n'est pas gaspillée et elle est même
moindre que l'énergie qu'il faudrait utiliser pour des modes de
développements classiques.

Cela dit, il existe une certaine quantité de cette énergie que l'on peut
sûrement récupérer. Mais attention, à force de penser en terme de
productivité et de temps perdu, tu risques de tuer le principal moteur
de ce mouvement : le plaisir !!!

> Il est donc capital de fournir des modèles réutilisables, à tous les
> niveaux possibles. Ainsi, toute application devrait être conçue de bas
> en haut. A savoir: fournir une bibliothèque de fonctions non
> interactives, au-dessus de laquelle seraient bâties les interfaces
> texte et graphique, avec un dialogue entre les deux niveaux, selon un
> protocole bien défini. A l'extrême, il serait ainsi possible
> d'intervenir dans une application graphique au moyen d'un simple
> script shell, par exemple.
> De même, la configuration d'une application devrait pouvoir se faire
> tant en mode texte, en éditant un fichier de configuration
> intelligible, qu'en mode graphique, par l'intermédiaire d'une
> application qui lirait ce même fichier de configuration et le
> modifierait, sans écraser les modifications faites à la main comme on
> le voit trop souvent !

Tout à fait d'accord! À condition de laisser la liberté de le faire ou
pas à ceux qui code. Il s'agit là tout au plus d'un conseil de
développement.

Te serais-tu vu en train de dire aux concepteurs de Gimp que ce n'était
pas bien d'intégrer leur bibliothèque graphique à leur logiciel dans
leur premières versions? Et si assomés par ce type de reproche, ils
avaient abandonné?

Bref, cela doit rester un conseil (qui de toute façon est suivi depuis
longtemps par bon nombre de programmeurs) et pas une obligation.

> Dans le même ordre d'idée, quel bonheur si les applications de même
> type fournissaient une interface standardisée (au niveau logiciel),
> à la manière du VFS (Virtual File System) pour les systèmes de fichiers,
> qui permettrait une modularité quasi-infinie.
> Par exemple, il deviendrait ainsi possible de commander le déplacement
> d'un fenêtre de manière non-interactive, ou de la changer d'écran
> virtuel d'une façon unique, sans ce soucier de savoir s'il on utilise
> AfterStep, WindowMaker, Fvwm, ou tout autre gestionnaire de fenêtre.

Euuuh, ça c'est de la théorie.... :-/

> S'il est vrai que le modèle "Bazar" possède de grandes forces,
> l'absence d'un architecte garantissant une cohérence d'ensemble se
> fait parfois cruellement sentir.

Et alors? Peut­être est-ce en partie grâce à cela que ça marche.

L'abscence de contraintes, de date limite, de hiérarchie (ou du moins
elle est réduite au minimum et les rapports ne sont pas des rapports de
force), ce que d'aucun appeleraient de l'anarchie donne un environnement
de travail agréable pour les hackeurs.

> Le défi crucial est la modularité, ce qui suppose de s'entendre sur
> une interface respectée par chacun. L'histoire prouve que jusqu'à
> présent, le souci de modularité n'a pas été assez poussé, du moins au
> niveau des applications. Soit. Il fallait bien un début.
> Mais maintenant que la machine est lancée, il faudrait imprimer une
> cohérence, des articulations communes.
> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
> chacune des équipes de développement, qui après avoir obtenu l'accord
> de tous, doit s'entendre avec elle pour définir un standard qui serait
> au moins un plus petit commun multiple des différentes fonctionnalités
> offertes.
>
> Ainsi, outre une facilité d'utilisation grandement accrue, cela
> permettrait à chacun de réinventer un peu moins la roue dans son coin,
> et de s'inscrire immédiatement dans un cadre cohérent.

AMHA, c'est une grosse erreur. Les hackeurs se sont toujours
auto-organisés jusqu'à présent. Les seules choses dont ils ont eu besoin
c'est de quelques leaders qui leur donnait une vision plus générale,
plus globale de leur mouvement (Stallman, Linus, Éric Raymond, ...). Ils
ont toujours su faire les bons choix pourquoi cela changerai?

À l'heure actuelle, je pense qu'il faut surtout informer les hackeurs
qu'un changement se profile à l'horizon et leur montrer comment marche
leur propre système. C'est à eux de choisir ensuite.

Je leur fais confiance. :-)

> P.S.: désolé pour la longueur excessive de ce post. Bravo à ceux qui
> ont tenu jusqu'ici.

J'ai déjà fait pire, et de toute façon c'était très intéréssant. :-)

Amicalement.
--
Emmanuel

"I would never die for my beliefs because I might be wrong."
Bertrand Russell.

[Pierre-Charles David]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:

> En ce qui concerne Microsoft, tout d'abord:
> - Microsoft n'a jamais rien inventé. S'il en est qui ont passé leur temps
> à copier les techniques existantes, puis à essayer de faire croire à de
> prétendues nouvelles inventions, c'est bien eux;

Tout a fait d'accord avec toi. (voir l'annonce de leur future souris
optique, presentee comme une innovation majeure: "the most radical
technology and design advance in the 30-year life of the mouse")

D'un autre cote, malgre tout le bien que je pense de logiciels libres
et du modele de developpement qui va avec, je me demande si la
communaute du LL est elle-meme capable d'innover vraiment.

Si on y regarde bien, a part quelques rares exemples (seuls Perl et
Python me viennent a l'esprit), aucune technologie innovante n'est
jamais sortie des LL. Bien sur, la communaute des programmeurs est
tres competente pour implementer dans standards existants (POSIX pour
Linux, X11 pour XFree86, CORBA pour Gnome, Gimp clone de
Photoshop...), mais tous ces standards existaient avant et sont issus
du monde de l'industrie et/ou de la recherche.

Est-ce qu'une bande de programmeurs non organises, meme tres
competents pour ce qui est de la programmation est vraiment capable de
creer du nouveau ? J'avoue avoir un gros doute la dessus (mais
j'espere me tromper).

--
Pierre-Charles David (da...@essi.fr)
Dieu dit: "M-x Lumière", et la lumière fut.

[Herve Eychenne]

Emmanuel Fleury <fle...@lsv.ens-cachan.fr> wrote:

> Réecrire du code ne revient pas à réinventer la roue, mais à inventer
> une nouvelle économie, une nouvelle culture. Au-dela du code, lorsqu'on
> écrit un programme GPL qui existait déjà sous licence fermée, on apporte
> une pierre à la création de l'édifice d'une économie basée dur les
> logiciels ouverts.

Entièrement d'accord.

> Personnellement, je ne pense pas comme les extrémistes que le marché du
> logiciel sera complétement recouvert par les logiciels libres (et même
> ouverts). Je crois qu'un certain équilibre s'instaurera entre les deux
> économies et que cet équilibre intégrera des logiciels ouverts et des
> logiciels fermés.

Je le crois aussi. Malheureusement.

> Les logiciels libres formeront un noyau fortement réutilisé par d'autres
> logiciels (compilateur, OS, bibliothèque de fonctions courantes,
> environnement graphique, ...). Les logiciels ouverts mais pas libres
> s'occuperont certainement des applications critiques (cryptographie,
> formats de documents, ...). Les logiciels fermés eux se partageront les
> applications de fin de chaîne (jeux, suites bureautiques, navigateur
> web, ...).

Cela ne suffit pas. Mais pourquoi ne pas imaginer que Linux induise une
profonde révolution dans la culture informatique, incitant les boîtes
commerciales à délivrer le code source de leurs applications ?
La machine est déjà lancée... Pourquoi le phénomène ne
s'auto-entretiendrait-il pas ?
(note: on s'éloigne du sujet initial)

>> - si la réutilisation de code était massive, une erreur détectée dans
>> un code source pourrait très bien s'être largement propagée, et serait
>> difficile à corriger dans tous les logiciels ayant repris cette
>> partie de code;

> En partie faux. La plupart des logiciels lorsqu'ils sont souvent
> utilisés par d'autres se transforment en bibliothèque qui permet
> d'inclure de façon dynamique le code dans les autres applications. Dès
> lors, la correction d'un bug sur la bibliothèque élimine le problème
> d'un coup sur toutes les applications d'un coup.

Et encore... les logiciels GNU (je n'ai pas dit "sous GPL !") utilisent
souvent un ensemble de fonctions regroupées sous forme de bibliothèque.
Il n'y a qu'à voir les différences de version de chacune de ses fonctions
dans les différents packages GNU pour se rendre compte que le problème
n'est pas si simple.
Mais, dois-je le préciser, je ne pensais pas aux bibliothèques quand je
parlais de réutilisation de code (par contre, j'avais pensé à le mettre,
mais je n'ai pas voulu rallonger un post déjà trop gros).

> L'exemple le plus flagrant et celui de Gimp qui à ses débuts incluait sa
> propre bibliothèque graphique à ses sources et qui a finalement
> développé Gtk de façon indépendante pour permettre à d'autres
> applications de l'utiliser.

Ce concept n'est pas assez repris...

> Il va falloir changer, et avoir une vision lucide sur ce qui faisait que
> cela marchait avant pour pouvoir l'adapter à ce qui va arriver dans
> notre futur proche. Par exemple reconnaitre le fait que Linux a besoin
> de simple utilisateurs serait un premier pas. :-)

Linux a besoin de simples utilisateurs, dans la mesure où ces derniers
peuvent contribuer à le rendre plus simple d'accès.
Maintenant, un nouvel utilisateur a rarement (par définition) les capacités
de modifier un logiciel pour le rendre plus conforme à ses désirs (si tant
est qu'il sache lui-même quels sont ses désirs !).
Cela implique donc que les développeurs (ayant les compétences techniques
pour faire avances les choses) prennent la chose en main. Déjà, il faut
qu'ils en aient envie, ce qui est loin d'être évident puisque ce qu'ils
ont sous la main leur convient très bien, vu leur niveau.
Ensuite, s'il y a une réelle volonté de leur part d'accroître l'ergonomie
du logiciel, il faudra qu'ils entrent en relation avec des utilisateurs
débutants, afin de dégager leurs besoins ! Pas simple, tout ça !

>> - le logiciel libre n'a pas empêché le développement de deux bureaux
>> comparables tels que Gnome et KDE, quelles qu'en soient les causes.
>> Sans compter la duplication de toutes les G_applications et
>> K_applications correspondantes. Que l'on soit pour l'un ou pour
>> l'autre, on ne peut s'empêcher de penser à un beau gâchis et à tout le
>> temps perdu.
>> A la limite, certains pourraient parler de la concurrence
>> Linux/FreeBSD. Mais ce serait sans doute une erreur: les problèmes
>> de la licence BSD sont suffisamment importants aux yeux de certains
>> pour justifier un développement parallèle;

> Encore une fois, le temps "perdu" est un faux argument. Tout cela repose
> encore sur une lutte entre logiciels libres et logiciels ouverts. Le
> conflit repose essentiellement sur la licence de Qt.

Oui et non, puisque les K_applications sont sous GPL. Mais je comprends
ce que tu veux dire.

> Tout simplement parcequ'entre une bibliothèque déjà installée et une
> nouvelle, la bibliothèque déjà installé l'aurait emporté sans laisser
> aucune chance à l'autre.

Exactement. On pensait que le logiciel libre était à l'abri de ce
genre de choses. Je crois bien qu'il n'en est rien. C'est bien triste,
mais c'est ainsi.
Il faut donc être extrêmement vigilant.

>> - le polymophisme des applications est une force, mais constitue trop
>> souvent un frein, devant l'accumulation de cas particuliers dans la
>> forme, mais redondants sur le fond;

> Oui et non. Encore une fois, je te le rappelle, c'est l'individu que
> cherche à favoriser la culture des logiciels ouverts. Permettre de
> choisir parmi un grand nombre de logiciels différents celui qui nous
> servira (même s'ils font la même chose) est un atout pour les individus
> et donc un gain de temps considérable pour chacun (cela lui évite
> d'avoir à développer ou modifier LE logiciel standard).

Tu m'as mal compris. Il ne s'agit pas de favoriser l'émergence d'*une*
application qui constituerait le standard de fait, mais plutôt de trouver
les points communs entre les différentes applications (de même type)
existantes, et d'en dégager une interface (au niveau logiciel, pas
forcément visuel) commune.

>> Des efforts de standardisation tels que le LSB sont à mon avis plus que
>> jamais nécessaires.

> De la même façon, on ne reprogramme plus la gestion de la souris ou

> celle des menus pour chaque application. On utilise des bibliothèques
> graphiques qui font tout ça. Bref, peu à peu, on standradise, on
> réutilise, on accumule une base.

> [...]

> Continuer cet effort me parait indispensable. L'encourager aussi. Mais
> prenez garde à la standardisation galopante. Vouloir imposer un standard
> qui n'en est pas un (i.e. qui n'est aps reconnu par tous) et le rendre
> inamovible avant l'heure est extrèmement risqué

Le standard doit être élaboré et accepté par tous. Sinon, il ne sert à
rien. En ce qui concerne le LSB, il devient urgent de déboucher sur
un compromis. Sinon on risque se retrouver dans un an avec une
cinquantaine de distributions différentes suffisamment incompatibles
entre elles pour freiner (tuer ?) le développement de Linux.

>> Il est donc capital de fournir des modèles réutilisables, à tous les
>> niveaux possibles. Ainsi, toute application devrait être conçue de bas
>> en haut. A savoir: fournir une bibliothèque de fonctions non
>> interactives, au-dessus de laquelle seraient bâties les interfaces
>> texte et graphique, avec un dialogue entre les deux niveaux, selon un
>> protocole bien défini. A l'extrême, il serait ainsi possible
>> d'intervenir dans une application graphique au moyen d'un simple
>> script shell, par exemple.
>> De même, la configuration d'une application devrait pouvoir se faire
>> tant en mode texte, en éditant un fichier de configuration
>> intelligible, qu'en mode graphique, par l'intermédiaire d'une
>> application qui lirait ce même fichier de configuration et le
>> modifierait, sans écraser les modifications faites à la main comme on
>> le voit trop souvent !

> Tout à fait d'accord! À condition de laisser la liberté de le faire ou
> pas à ceux qui code. Il s'agit là tout au plus d'un conseil de
> développement.

Bien sûr. Mais un conseil qu'il seraient fortement avisés de suivre !! ;-)

> Te serais-tu vu en train de dire aux concepteurs de Gimp que ce n'était
> pas bien d'intégrer leur bibliothèque graphique à leur logiciel dans
> leur premières versions? Et si assomés par ce type de reproche, ils
> avaient abandonné?

Pour Gimp, tout restait à créer. Il faut bien un début, quel qu'il soit.
C'est le fait de savoir s'organiser une fois le développement
suffisamment amorcé, qui est important.

> Bref, cela doit rester un conseil (qui de toute façon est suivi depuis
> longtemps par bon nombre de programmeurs) et pas une obligation.

Et pourtant, cela devrait être une obligation (morale).

>> Dans le même ordre d'idée, quel bonheur si les applications de même
>> type fournissaient une interface standardisée (au niveau logiciel),
>> à la manière du VFS (Virtual File System) pour les systèmes de fichiers,
>> qui permettrait une modularité quasi-infinie.
>> Par exemple, il deviendrait ainsi possible de commander le déplacement
>> d'un fenêtre de manière non-interactive, ou de la changer d'écran
>> virtuel d'une façon unique, sans ce soucier de savoir s'il on utilise
>> AfterStep, WindowMaker, Fvwm, ou tout autre gestionnaire de fenêtre.

> Euuuh, ça c'est de la théorie.... :-/

N'est-ce pas le fin du fin ? Si oui, qu'est-ce qui empêche d'y parvenir ?
Pourquoi ce rêve semble-t-il inaccessible ? Peut-être parce que le modèle
de développement libre n'est pas de nature à favoriser une telle
organisation...
On peut tout de même essayer de faire quelque chose, non ? Ou c'est perdu
d'avance ?

>> S'il est vrai que le modèle "Bazar" possède de grandes forces,
>> l'absence d'un architecte garantissant une cohérence d'ensemble se
>> fait parfois cruellement sentir.

> Et alors? Peut­être est-ce en partie grâce à cela que ça marche.

Oui, sans doute. Ce modèle apparemment anarchique a quelque chose de
fascinant pour l'homme, qui tend naturellement à développer des
structures plus hiérarchisées. Mais il ne faudrait pas que la fascination
occulte des problèmes bien réels.

>> Le défi crucial est la modularité, ce qui suppose de s'entendre sur
>> une interface respectée par chacun. L'histoire prouve que jusqu'à
>> présent, le souci de modularité n'a pas été assez poussé, du moins au
>> niveau des applications. Soit. Il fallait bien un début.
>> Mais maintenant que la machine est lancée, il faudrait imprimer une
>> cohérence, des articulations communes.
>> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
>> chacune des équipes de développement, qui après avoir obtenu l'accord
>> de tous, doit s'entendre avec elle pour définir un standard qui serait
>> au moins un plus petit commun multiple des différentes fonctionnalités
>> offertes.

>> Ainsi, outre une facilité d'utilisation grandement accrue, cela
>> permettrait à chacun de réinventer un peu moins la roue dans son coin,
>> et de s'inscrire immédiatement dans un cadre cohérent.

> AMHA, c'est une grosse erreur. Les hackeurs se sont toujours
> auto-organisés jusqu'à présent.

Oui... Autrefois, cela allait bien, vu la nature des projets.
Aujourd'hui, avec le développement d'interfaces graphiques (qui sont
rarement le fait de ces mêmes hackeurs), je trouve que ça ne suffit plus.

> Les seules choses dont ils ont eu besoin
> c'est de quelques leaders qui leur donnait une vision plus générale,
> plus globale de leur mouvement (Stallman, Linus, Éric Raymond, ...). Ils
> ont toujours su faire les bons choix pourquoi cela changerai?

Parce que les projets ont changé de taille et de nature.

>> P.S.: désolé pour la longueur excessive de ce post. Bravo à ceux qui
>> ont tenu jusqu'ici.

> J'ai déjà fait pire,

Exemple encore une fois renouvelé, s'il en était besoin. ;-)

RV

[Herve Eychenne]

emmanue...@skynet.be wrote:
> On 26 Apr 1999 03:49:26 GMT, Herve Eychenne
> <eych...@info.enserb.u-bordeaux.fr> wrote:

> [trop long, même si c'était intéressant, pour tout reprendre]

> Je pense que le moyen le plus efficace pour avoir une certaine
> cohérence, et surtout une bonne modularité parmi toutes les applis
> libres est de s'attacher à respecter des standards reconnus.

Ou éventuellement de créer ces standards. Je veux dire par là, mettre
au point une structure, un cadre, et essayer de favoriser la pousse
de la plante dans les croisions. ;-)

> Et notamment CORBA qui peut résoudre, AMHA de profane car je ne l'ai
> que survolé, beaucoup de problème de réutilisation du code vu qu'il
> n'est pas tributaire d'un langage.

CORBA est intéressant, mais il ne répond pas à tous les problèmes.

> A ce titre Gnome (et aussi KDE non ?!) me paraît être prometteur.

KDE n'est pas basé sur Corba, que je sache...
L'utilisation de Corba est intéressante, mais contribue à générer des
obèsiciels.
Et puis il ne suffit pas sauter sur sa chaise comme un cabri en criant
"CORBA, CORBA !!". Eh puis, c'est parfois le marteau pillon pour écraser
la mouche.

> D'un autre côté le foisonnement de solutions diverses et variées est
> en-soi une perte de temps à priori, mais de cette diversité naissent
> des solutions nouvelles peut-être plus mûres car ayant bénéficiées
> des expériences précédentes.

Mais je suis bien d'accord. Seulement, ce n'est qu'une partie du
problème. Si tout le monde, développe dans son coin, il n'y aura
jamais de cohérence globale. Tout juste une progression en escalier.

> Par exemple GGI/Berlin semblent réinventer la roue, mais peut-être
> pour fournir une base bien plus souple à l'avenir? (j'espère que
> ceux qui en savent un peu plus long que moi sur ce projet me
> corrigeront :)

Berlin n'est pas moribond ?

> Pour ce qui est des distributions, LSB et FHS me paraissent aller dans
> le bon sens (mais à quelle vitesse ?), encore faut-il qu'elles le
> respectent toutes (qu'en-est-il actuellement ?).

A vitesse lente.
http://www.linuxworld.com/linuxworld/lw-1999-04/lw-04-lsb.html

RV

[Emmanuel Fleury]

Herve Eychenne wrote:
>
> > Personnellement, je ne pense pas comme les extrémistes que le marché du
> > logiciel sera complétement recouvert par les logiciels libres (et même
> > ouverts). Je crois qu'un certain équilibre s'instaurera entre les deux
> > économies et que cet équilibre intégrera des logiciels ouverts et des
> > logiciels fermés.
>
> Je le crois aussi. Malheureusement.

Pourquoi "malheureusement"? Laisser une place pour chacun est une bonne
chose. Vouloir l'éradication d'une forme de pensée, même si on la
considère comme mauvaise (dans sa façon de voir du moment) EST une
mauvaise chose.

> Cela ne suffit pas. Mais pourquoi ne pas imaginer que Linux induise une
> profonde révolution dans la culture informatique, incitant les boîtes
> commerciales à délivrer le code source de leurs applications ?
> La machine est déjà lancée... Pourquoi le phénomène ne
> s'auto-entretiendrait-il pas ?

Mais je ne dis pas le contraire. Linux (et tous les logiciels ouverts)
est en train de révolutionner le marché et la conception des logiciels.
De plus le mouvement a acquis suffisamment d'ampleur à l'heure actuelle
pour ne plus être inquiété par les "géants" de l'ère précédente (aka
Microsoft et IBM) qui lui prétent même main forte (pour IBM tout du
moins).

> (note: on s'éloigne du sujet initial)

Voui! :-/

> Et encore... les logiciels GNU (je n'ai pas dit "sous GPL !") utilisent
> souvent un ensemble de fonctions regroupées sous forme de bibliothèque.
> Il n'y a qu'à voir les différences de version de chacune de ses fonctions
> dans les différents packages GNU pour se rendre compte que le problème
> n'est pas si simple.
> Mais, dois-je le préciser, je ne pensais pas aux bibliothèques quand je
> parlais de réutilisation de code (par contre, j'avais pensé à le mettre,
> mais je n'ai pas voulu rallonger un post déjà trop gros).

Ok, je comprend mieux.

> Linux a besoin de simples utilisateurs, dans la mesure où ces derniers
> peuvent contribuer à le rendre plus simple d'accès.
> Maintenant, un nouvel utilisateur a rarement (par définition) les capacités
> de modifier un logiciel pour le rendre plus conforme à ses désirs (si tant
> est qu'il sache lui-même quels sont ses désirs !).
> Cela implique donc que les développeurs (ayant les compétences techniques
> pour faire avances les choses) prennent la chose en main. Déjà, il faut
> qu'ils en aient envie, ce qui est loin d'être évident puisque ce qu'ils
> ont sous la main leur convient très bien, vu leur niveau.
> Ensuite, s'il y a une réelle volonté de leur part d'accroître l'ergonomie
> du logiciel, il faudra qu'ils entrent en relation avec des utilisateurs
> débutants, afin de dégager leurs besoins ! Pas simple, tout ça !

C'est un peu un cycle dans lequel nous ne sommes pas encore rentré.

Les utilisateurs demanderont plus de simplifications aux développeurs.
Et ces simplifications (n'en déplaisent à certains) profiteront aux
développeurs et attireront plus débutants parmi les développeurs. Et
ceux-ci programmerons des logiciels qui attireront plus d'utilisateurs
qui demanderont plus de simplifications, ....

Mais entrer dans la boucle va être dûr. Cela a déjà commencé, cela
continuera. Ceux qui refuseront d'y rentrer utiliseront des outils peu
performants et se verront bien vite dépassés. Les autres en retireront
un énorme bénéfice... AMHA.

> Exactement. On pensait que le logiciel libre était à l'abri de ce
> genre de choses. Je crois bien qu'il n'en est rien. C'est bien triste,
> mais c'est ainsi.

On ne va pas reprocher aux hommes d'être humains! :-)

> Il faut donc être extrêmement vigilant.

Oui.

> Tu m'as mal compris. Il ne s'agit pas de favoriser l'émergence d'*une*
> application qui constituerait le standard de fait, mais plutôt de trouver
> les points communs entre les différentes applications (de même type)
> existantes, et d'en dégager une interface (au niveau logiciel, pas
> forcément visuel) commune.

C'est beau à dire mais difficile à réaliser.

Je garde plus ou moins un optimisme béat et je fais confiance à la
communauté des hackeurs pour faire ce genre de choix de façon implicite.

Le faire de façon explicite (avec des textes, des conseils, etc)
risquerait fort d'être interprété comme des commandements et pas suivi.

Ou alors, il faudrait sortir un document semblable au : GNU Coding
Standards
( http://www.fsf.org/prep/standards_toc.html ) de la FSF. Un ensemble de
conseils qui permette de comprendre l'esprit dans lequel tu "devrais"
coder ton logiciel.

> Le standard doit être élaboré et accepté par tous. Sinon, il ne sert à
> rien. En ce qui concerne le LSB, il devient urgent de déboucher sur
> un compromis. Sinon on risque se retrouver dans un an avec une
> cinquantaine de distributions différentes suffisamment incompatibles
> entre elles pour freiner (tuer ?) le développement de Linux.

Cela dépend de ce que tu veux imposer, mais il vrai que s'entendre, par
exemple, sur une arborescence unique serait une bonne chose (SuSe est
l'une des seule distribution à n'en faire qu'à sa tête et cela rend sa
gestion assez difficile par un habitué d'une autre distribution...)

Donc, d'accord avec toi dans la mesure où tu n'imposes pas de trop
grandes contraintes.

> > Bref, cela doit rester un conseil (qui de toute façon est suivi depuis
> > longtemps par bon nombre de programmeurs) et pas une obligation.
>
> Et pourtant, cela devrait être une obligation (morale).

Oui! Mais pas plus. :-)

> > Euuuh, ça c'est de la théorie.... :-/
>
> N'est-ce pas le fin du fin ? Si oui, qu'est-ce qui empêche d'y parvenir ?
> Pourquoi ce rêve semble-t-il inaccessible ? Peut-être parce que le modèle
> de développement libre n'est pas de nature à favoriser une telle
> organisation...

La seule chance pour arriver à ce résultat rapidement était d'utiliser
CORBA, or celui-ci est abandonné au profit de Java (ce qui, AMHA, est
une bétise). Voir : http://www.objectwatch.com/issue19.htm

Peut-être que CORBA sera repris par les logiciels libres et continuera a
être développé.

À voir donc, l'avenir nous le dira. Cela dit ce n'est pas aussi
théorique que ce que je disais. :-)

> On peut tout de même essayer de faire quelque chose, non ? Ou c'est perdu
> d'avance ?

Bien sûr, en étant même un brin optimiste, on peut même se dire qu'on va
réussir. :-)

> Oui, sans doute. Ce modèle apparemment anarchique a quelque chose de
> fascinant pour l'homme, qui tend naturellement à développer des
> structures plus hiérarchisées. Mais il ne faudrait pas que la fascination
> occulte des problèmes bien réels.

Attention, il n'est anarchique qu'en surface. Ou plutôt, il est
anarchique par rapport à la vision établie de "l'ordre" que l'on a
actuellement. Il continue à exister des chefs (de projet), il continue à
y avoir des pressions entre les communautés, il continue à y avoir des
projets avortés (mes essais de forums par exemple :-)), cependant, les
libertés individuelles priment et c'est en voyant cela qu'on croit voir
l'anarchie (AMHA).

> > AMHA, c'est une grosse erreur. Les hackeurs se sont toujours
> > auto-organisés jusqu'à présent.
>
> Oui... Autrefois, cela allait bien, vu la nature des projets.
> Aujourd'hui, avec le développement d'interfaces graphiques (qui sont
> rarement le fait de ces mêmes hackeurs), je trouve que ça ne suffit plus.

Pourquoi? Qu'est-ce qui te fais penser cela?

> > Les seules choses dont ils ont eu besoin
> > c'est de quelques leaders qui leur donnait une vision plus générale,
> > plus globale de leur mouvement (Stallman, Linus, Éric Raymond, ...). Ils
> > ont toujours su faire les bons choix pourquoi cela changerai?
>
> Parce que les projets ont changé de taille et de nature.

Tu sais, entre le moment où Linus a commencé à développer un noyau pour
s'amuser et s'instruire et aujourd'hui combien de fois crois-tu qu'il
s'est retrouvé dans un cas où il a dû changer de modèle?

Passer de 10 utilisateurs à 100, puis à 1000, puis à 1000000 ne se fait
pas sans repenser quelques petites choses.

Aujourd'hui on compte plus sur l'auto-stabilisation que sur les
comportements individuels. C'est peut-être un tort, mais à vrai dire on
a plus vraiment le choix. Une personne seule ne peut avoir l'approbation
d'un aussi grand nombre de personnes sans rencontrer, au moins, une
resistance quelque part.

Cela dit, je ne dit pas qu'il faut rester passif. Si l'on croit à ses
idées il faut les diffuser, les marteler s'il le faut, jusqu'à ce
qu'elle passent ou que l'on soit convaincu qu'elles sont fausses. Les
évolutions de mentalités au sein des communautés se font toujours avec
des frictions. Les logiciels libres ont déjà eu leur révolution. Le "roi
Stallman" est en bas de son trône et Linux a repris le flambeau en étant
plus démocratique. À présent, c'est le "mai 68" de Linux que l'ont
attend avec impatience.

Celui-là est plus court normalement. :-)

[Herve Eychenne]

Emmanuel Fleury <fle...@lsv.ens-cachan.fr> wrote:

>> > Personnellement, je ne pense pas comme les extrémistes que le marché du
>> > logiciel sera complétement recouvert par les logiciels libres (et même
>> > ouverts). Je crois qu'un certain équilibre s'instaurera entre les deux
>> > économies et que cet équilibre intégrera des logiciels ouverts et des
>> > logiciels fermés.

>> Je le crois aussi. Malheureusement.

> Pourquoi "malheureusement"? Laisser une place pour chacun est une bonne
> chose. Vouloir l'éradication d'une forme de pensée, même si on la
> considère comme mauvaise (dans sa façon de voir du moment) EST une
> mauvaise chose.

Vraiment ? Puisque tu généralises, je peux te prendre bêtement au mot.
Dans un tout autre contexte (on ne peut plus extrême), vouloir éradiquer
les thèses révisionnistes est une mauvaise chose, selon toi ?

"Pas de liberté pour les ennemis de la liberté".
Cette fameuse phrase révolutionnaire est encore d'actualité.

Dans bon nombre de matières scientifiques, les découvertes sont
largement partagées et entrent directement dans le domaine public.
En informatique, il ne s'agit même pas de cela. Tout ce que l'on
demande, c'est de pouvoir vérifier par soi-même, si on le souhaite,
le comportement des logiciels que l'on utilise, et que l'on puisse
en acquérir une expérience réutilisable.

>> Ensuite, s'il y a une réelle volonté de leur part d'accroître l'ergonomie
>> du logiciel, il faudra qu'ils entrent en relation avec des utilisateurs
>> débutants, afin de dégager leurs besoins ! Pas simple, tout ça !

> C'est un peu un cycle dans lequel nous ne sommes pas encore rentré.

> Les utilisateurs demanderont plus de simplifications aux développeurs.
> Et ces simplifications (n'en déplaisent à certains) profiteront aux
> développeurs et attireront plus débutants parmi les développeurs. Et
> ceux-ci programmerons des logiciels qui attireront plus d'utilisateurs
> qui demanderont plus de simplifications, ....

A condition que les simplifications en question ne soient qu'une
surcouche d'un niveau plus complexe, et pas un masquage d'informations !!
J'insiste !

> Mais entrer dans la boucle va être dûr. Cela a déjà commencé, cela
> continuera. Ceux qui refuseront d'y rentrer utiliseront des outils peu
> performants et se verront bien vite dépassés.

Non... Une surcouche simplifiée peut faire gagner du temps à certains,
mais peut constituer un frein pour ceux qui savent faire des choses
moins conviviales, mais plus puissantes.
Chacun doit pouvoir adopter le niveau d'abstraction qui lui convient,
et en changer s'il le désire.

>> Exactement. On pensait que le logiciel libre était à l'abri de ce
>> genre de choses. Je crois bien qu'il n'en est rien. C'est bien triste,
>> mais c'est ainsi.

> On ne va pas reprocher aux hommes d'être humains! :-)

Ce que je veux dire, c'est que les nouveaux utilisateurs semblent moins
à même de faire les bon choix qu'autrefois.

>> Tu m'as mal compris. Il ne s'agit pas de favoriser l'émergence d'*une*
>> application qui constituerait le standard de fait, mais plutôt de trouver
>> les points communs entre les différentes applications (de même type)
>> existantes, et d'en dégager une interface (au niveau logiciel, pas
>> forcément visuel) commune.

> C'est beau à dire mais difficile à réaliser.

Je suis bien d'accord. Ce n'est pas pour ça que je vais m'abstenir de
le dire. ;-)
Et si j'ai le temps, je suis même prêt à monter un projet allant dans ce
sens.

> Je garde plus ou moins un optimisme béat

La béatitude aveugle. ;-)

> et je fais confiance à la communauté des hackeurs pour faire ce
> genre de choix de façon implicite.

Mais l'histoire a prouvé que ces choix n'ont pas été faits jusqu'à
présent !

> Le faire de façon explicite (avec des textes, des conseils, etc)
> risquerait fort d'être interprété comme des commandements et pas
> suivi.

Personne ne peut obliger les gens à suivre ses conseils, même s'ils
sont bons.

> Ou alors, il faudrait sortir un document semblable au : GNU Coding
> Standards
> ( http://www.fsf.org/prep/standards_toc.html ) de la FSF. Un ensemble de
> conseils qui permette de comprendre l'esprit dans lequel tu "devrais"
> coder ton logiciel.

Pourquoi pas.

>> Le standard doit être élaboré et accepté par tous. Sinon, il ne sert à
>> rien. En ce qui concerne le LSB, il devient urgent de déboucher sur
>> un compromis. Sinon on risque se retrouver dans un an avec une
>> cinquantaine de distributions différentes suffisamment incompatibles
>> entre elles pour freiner (tuer ?) le développement de Linux.

> Cela dépend de ce que tu veux imposer, mais il vrai que s'entendre, par
> exemple, sur une arborescence unique serait une bonne chose (SuSe est
> l'une des seule distribution à n'en faire qu'à sa tête et cela rend sa
> gestion assez difficile par un habitué d'une autre distribution...)

Il paraîtrait que ça se serait un peu arrangé (pour Suse) ?
C'est ce que m'ont dit des linuxiens strasbourgeois.
Je n'ai pas encore vérifié.

>> > Euuuh, ça c'est de la théorie.... :-/

>> N'est-ce pas le fin du fin ? Si oui, qu'est-ce qui empêche d'y parvenir ?
>> Pourquoi ce rêve semble-t-il inaccessible ? Peut-être parce que le modèle
>> de développement libre n'est pas de nature à favoriser une telle
>> organisation...

> La seule chance pour arriver à ce résultat rapidement était d'utiliser
> CORBA, or celui-ci est abandonné au profit de Java (ce qui, AMHA, est
> une bétise). Voir : http://www.objectwatch.com/issue19.htm

Oui, j'ai vu...

> Peut-être que CORBA sera repris par les logiciels libres et continuera a
> être développé.

Je suis assez sceptique...

>> Oui, sans doute. Ce modèle apparemment anarchique a quelque chose de
>> fascinant pour l'homme, qui tend naturellement à développer des
>> structures plus hiérarchisées. Mais il ne faudrait pas que la fascination
>> occulte des problèmes bien réels.

> Attention, il n'est anarchique qu'en surface. Ou plutôt, il est
> anarchique par rapport à la vision établie de "l'ordre" que l'on a
> actuellement. Il continue à exister des chefs (de projet), il continue à
> y avoir des pressions entre les communautés, il continue à y avoir des
> projets avortés (mes essais de forums par exemple :-)), cependant, les
> libertés individuelles priment et c'est en voyant cela qu'on croit voir
> l'anarchie (AMHA).

Oui. Mais les libertés individuelles sans un minimum d'ordre, ça peut
vite dégénérer lorsqu'on n'est pas entre gens sensés.

>> > AMHA, c'est une grosse erreur. Les hackeurs se sont toujours
>> > auto-organisés jusqu'à présent.

>> Oui... Autrefois, cela allait bien, vu la nature des projets.
>> Aujourd'hui, avec le développement d'interfaces graphiques (qui sont
>> rarement le fait de ces mêmes hackeurs), je trouve que ça ne suffit plus.

> Pourquoi? Qu'est-ce qui te fais penser cela?

Je ne connais pas *une* seule application qui soit conforme à ce que
j'imaginerais (détaillé dans le post initial).
Linuxconf est très bien conçu (de façon très modulaire), mais il a la
fâcheuse manie (rédhibitoire) d'écraser les modifications faites
par d'autres biais que lui.
Donc, recalé. ;-) Dommage...

> Cela dit, je ne dit pas qu'il faut rester passif. Si l'on croit à ses
> idées il faut les diffuser, les marteler s'il le faut, jusqu'à ce
> qu'elle passent ou que l'on soit convaincu qu'elles sont fausses. Les
> évolutions de mentalités au sein des communautés se font toujours avec
> des frictions. Les logiciels libres ont déjà eu leur révolution. Le "roi
> Stallman" est en bas de son trône et Linux a repris le flambeau en étant
> plus démocratique. À présent, c'est le "mai 68" de Linux que l'ont
> attend avec impatience.

Quelle exhaltation...
Moi tout ce que je crois c'est que si personne ne propose un modèle
peu cohérent, il ne risque pas d'émerger par l'opération du saint-esprit.

[Emmanuel Fleury]

Herve Eychenne wrote:
>
> Vraiment ? Puisque tu généralises, je peux te prendre bêtement au mot.
> Dans un tout autre contexte (on ne peut plus extrême), vouloir éradiquer
> les thèses révisionnistes est une mauvaise chose, selon toi ?
>
> "Pas de liberté pour les ennemis de la liberté".
> Cette fameuse phrase révolutionnaire est encore d'actualité.
>
> Dans bon nombre de matières scientifiques, les découvertes sont
> largement partagées et entrent directement dans le domaine public.
> En informatique, il ne s'agit même pas de cela. Tout ce que l'on
> demande, c'est de pouvoir vérifier par soi-même, si on le souhaite,
> le comportement des logiciels que l'on utilise, et que l'on puisse
> en acquérir une expérience réutilisable.

Je précise que je reste dans le cadre des droits de l'homme (qui est,
selon moi, un invariant). Dès l'instant que l'on nuit à autrui de façon
trop évidente, c'est mal.

Pour moi, c'était évident.

> A condition que les simplifications en question ne soient qu'une
> surcouche d'un niveau plus complexe, et pas un masquage d'informations !!
> J'insiste !

Tout à fait d'accord aussi.

> Non... Une surcouche simplifiée peut faire gagner du temps à certains,
> mais peut constituer un frein pour ceux qui savent faire des choses
> moins conviviales, mais plus puissantes.
> Chacun doit pouvoir adopter le niveau d'abstraction qui lui convient,
> et en changer s'il le désire.

Vrai aussi. À la nuance près qu'une fois qu'on sait faire une fstab
correcte, il est inutile de monter ses partitions à la main. Cliquer sur
l'icône du lecteur de CD-ROM est amplement suffisant et n'enlève aucune
connaissance à l'utilisateur (pour peu qu'il ai fait son fstab
lui-même).

De plus, je pensai surtout aux environnements de développement. Le
discour que tu tiens, des tas de gens qui codaient en assembleurs l'ont
tenu il y a 10 ans et aujourd'hui qui a gagné?

Mais aujourd'hui beaucoup plus de choses sont prises en charge par les
machines et non plus par les développeurs (pour tout dire on serait
incapable de construire les processeurs actuels sans utiliser la
puissance de calcul des processeurs de la génération précedente).

En fait, l'encapsulation de la machine et sa prise en charge automatique
par les compilateur et les langages est de plus en plus efficace. Les
langages fonctionnels (caml, objective-caml) et les langages objets
(java, C++) permettent d'envisager l'informatique sous des angles
totalement différents d'il y a 10 ans (les compilateurs analysent le
code de façon beaucoup plus fine et optimisent comme aucun humain ne le
pourrai) et apportent une vision plus théorique et plus "pure" de
l'informatique (on se dirige vers une informatique plus conceptuelle et
plus mathématique).

Les débuts du pi-calculs présagent d'une sorte de lambda-calcul (lisp,
ada, caml) du parallélisme et des programmes distribués sont très
encourageants.

Bref, les fondements théoriques convergent vers un but unique :
encapsuler l'informatique dans des concepts qui rendront la
programmation plus facile. C'est ce qui s'est produit avec l'assembleur
et c'est probablement ce qui va se produire dans le futur à un niveau
plus élevé encore.

Mais , c'est une autre histoire.

> Je suis bien d'accord. Ce n'est pas pour ça que je vais m'abstenir de
> le dire. ;-)
> Et si j'ai le temps, je suis même prêt à monter un projet allant dans ce
> sens.

Oui.

> > Je garde plus ou moins un optimisme béat
>
> La béatitude aveugle. ;-)

Un peu.

> Mais l'histoire a prouvé que ces choix n'ont pas été faits jusqu'à
> présent !

Où est la preuve? L'évolution s'est bien passée jusqu'à présent, non?

> Il paraîtrait que ça se serait un peu arrangé (pour Suse) ?
> C'est ce que m'ont dit des linuxiens strasbourgeois.
> Je n'ai pas encore vérifié.

Je ne savais pas.

> Je ne connais pas *une* seule application qui soit conforme à ce que
> j'imaginerais (détaillé dans le post initial).
> Linuxconf est très bien conçu (de façon très modulaire), mais il a la
> fâcheuse manie (rédhibitoire) d'écraser les modifications faites
> par d'autres biais que lui.
> Donc, recalé. ;-) Dommage...

C'est vrai. Je suis assez d'accord avec toi sur ce point là. Mais je
pense que Gnome est un excellent début (implicite) de standardisation.
Qu'en penses-tu?

Amicalement

[Stephane TOUGARD]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> wrote:
> Lu sur slashdot:
> "Un article du Chicago Tribune suggère que la somme d'efforts
> déployés pour Linux serait mieux rentablilisée (en terme de temps)
> en contribuant à l'amélioration des logiciels Microsoft.
> L'auteur souligne que Linux est entrain de réinventer la roue.
> Linux n'est-il pas une perte de temps ?"

Allez, il faut mieux lire cela que d'etre aveugle.

> - si la réutilisation de code était massive, une erreur détectée dans
> un code source pourrait très bien s'être largement propagée, et serait
> difficile à corriger dans tous les logiciels ayant repris cette
> partie de code;

Grace a l'utilisation des liens dynamiques, a la gestion du devel via
des outils adaptes (gestion des version,...), ce type d'erreur n'est pas
vraiment a redouter.

> - le développement du logiciel libre est assez anarchique. S'il est vrai
> que tout système tend à s'auto-organiser, il n'empêche que l'entropie
> augmente. Trop de programmeurs semblent se lancer dans un projet sans
> prendre la peine de se renseigner pour savoir ce qui a été effectué
> auparavant sur le sujet;

Cela ne fait que plus de projets, plus de choix. Nous avons les moyens
de coder dans tous les sens, notre main d'oeuvre est infinie (ou
presque, en tout cas elle a des moyens que meme MS n'a pas).

> - le logiciel libre n'a pas empêché le développement de deux bureaux
> comparables tels que Gnome et KDE, quelles qu'en soient les causes.
> Sans compter la duplication de toutes les G_applications et
> K_applications correspondantes. Que l'on soit pour l'un ou pour
> l'autre, on ne peut s'empêcher de penser à un beau gâchis et à tout le
> temps perdu.

Meme argument, et alors ? L'existence de Gnome ne remet pas en cause
celle de Kde, celle de Sendmail contre Exim,... Plus de choix, du
gachis, on s'en fout.

> A la limite, certains pourraient parler de la concurrence
> Linux/FreeBSD. Mais ce serait sans doute une erreur: les problèmes
> de la licence BSD sont suffisamment importants aux yeux de certains
> pour justifier un développement parallèle;

Il n'y a pas de concurrence, FreeBSD existe, Linux existe et chacun
existera tant qu'un seul individu en gardera un sur sa machine. Il n'y a
pas de fric dans cette affaire (en tous cas, pas a ce niveau la), on ne
peut parler de concurrence. Longue vie a Linux, FreeBSD, OpenBSD,...

> - le polymophisme des applications est une force, mais constitue trop
> souvent un frein, devant l'accumulation de cas particuliers dans la
> forme, mais redondants sur le fond;

Cela ne me gene pas et je doute que cela gene bcp de monde.

> - chacun refait tout de même un peu les mêmes choses dans son coin.
> Par exemple, il est regrettable que les différentes distributions de
> Linux améliorent leurs procédures d'installation en parallèle, sans
> que les uns bénéficient directement des avancées des autres.
> Si chacun s'était entendu sur un standard commun (de nivellement par
> le haut, cela va de soi), que d'efforts auraient été épargnés...

Plus il y aura de distributions, plus il y aura de supports pour porter
Linux, le seul regret que j'ai avec FreeBSD, c'est son manque
d'innovation au niveau des distribs.

> Des efforts de standardisation tels que le LSB sont à mon avis plus que
> jamais nécessaires.

Necessaires ? pratique, oui, mais necessaires,...

> On assiste donc à une pseudo organisation de type fourmilière, où
> l'ensemble de l'ouvrage finit tout de même par prendre forme, mais
> au prix d'un déploiement d'énergie trop souvent gaspillée.

Mais qui ne coute rien, le rapport est au contraire enorme, le gain est
a 100 %. Jamais un systeme n'aura ete aussi rentable.

> Dans le même ordre d'idée, quel bonheur si les applications de même
> type fournissaient une interface standardisée (au niveau logiciel),
> à la manière du VFS (Virtual File System) pour les systèmes de fichiers,
> qui permettrait une modularité quasi-infinie.

Beurk, il y en a qui preferent sendmail et d'autres qmail ou exim, et
souvent c'est pour la maniere de configurer l'un ou l'autre que la
preference s'etablit. La richesse est dans le choix.

> Ainsi, outre une facilité d'utilisation grandement accrue, cela
> permettrait à chacun de réinventer un peu moins la roue dans son coin,
> et de s'inscrire immédiatement dans un cadre cohérent.

Pour un truc incoherent, Linux peut tourner sur plein d'architectures
avec une stabilite que Windows ou MacOS ne sont meme pas capable
d'envisager, avec un choix d'applicatifs a faire palir n'importe quel
OS. Si Windows est plus coherent, alors que j'aime l'incoherence.

--
À Jonathan SWIFT, qui après avoir décrit la justice, la médecine et
l'Etat d'un oeil critique ajouta : "Le lecteur s'étonnera peut-être
que j'ai pu me résoudre à représenter mon espèce sous un jour aussi
fidèle" Les voyages de Gulliver 4ème partie chapitre 7.

[Eric Jacoboni]

"Stephane TOUGARD" <el...@teaser.fr> writes:

> le seul regret que j'ai avec FreeBSD, c'est son manque
> d'innovation au niveau des distribs.

Mouais... Finalement, je trouve ça plutôt pas mal, moi. Une seule
distrib, plusieurs déclinaisons (CURRENT, STABLE, RELEASE) : ça laisse
de la place pour tout le monde (prudents, pressés, aventureux) et ça
évite de voir ce que l'on voit sous Linux, des distribs toutes aussi
incompatibles les unes que les autres, des systèmes de paquetages
différents, des méthodes de mises à jour différentes, etc.

De toutes façons, à bien y regarder, quels sont les avantages des
distribs ? Elles contiennent toutes la même chose... Ce qui change,
c'est le système de paquetage, les choix techniques, la facilité
d'installation... : on arrive vite à devoir sortir de cet
emprisonnement pour se peaufiner son système et on a donc créé sa
propre distrib... Pareil avec FBSD : il y a le truc de base, après on
installe ses trucs via les ports, ou à la mano si cela n'a pas été
porté... et quand on y a réussi, on écrit le port, basta.

Cette unicité a, en tous cas, un intérêt : un pb sous FBSD est un pb
FBSD, alors que souvent les pbs Linux se ramènent à des pbs de
distribs. Je suis bien placé pour le savoir : écrire une doc quelle
qu'elle soit pour Linux est un véritable cauchemar car si l'on se base
sur une distrib, cela ne marchera pas sur une autre (dernier exemple
en date : PostgreSQL...). On est donc obligé, finalement, de
s'abstraire de toute distrib pour faire une doc un tant soit peu
générale et donc exit Linux.

Mon avis à moi que j'ai, en tous cas.

--
---------------------------------------------------------
Éric Jacoboni « No sport, cigars! » (W. Churchill)
---------------------------------------------------------

[Julien Plissonneau Duquene]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:

> L'auteur souligne que Linux est entrain de réinventer la roue.

Il a rate le fait que ce coup ci le but est d'inventer la roue une
bonne fois pour toutes.

> Pas un de leurs systèmes d'exploitation successifs n'a jamais valu le
> moindre centime.

Je ne suis pas d'accord. Le noyau NT aurait pu etre interessant, mais
ces sagouins n'ont pas daigne documenter ses appels systeme.
Effectivement, le reste n'est pas terrible ...

> - il est moins que certain que le fait de mettre son talent
> bénévolement au service d'une firme aussi mercantile que Microsoft
> entousiasme les développeurs de Linux;

Pas si sur (cf Wine, Cygnus, djgpp, Apache/win32). Mais c'est vrai que
travailler avec des systemes documentes et dont on dispose du code
source, c'est plus motivant, ne serait-ce qu'en reduisant le temps
passe a faire des hypotheses sur le fonctionnement d'un appel systeme.

> Pour ce qui est du logiciel libre:

> - le temps n'est pas la préoccupation principale. C'est la qualité du
> produit fini qui compte.

Je ne crois pas qu'on puisse parler de produit fini dans le cadre du
LL. En general on dispose plutot d'outils sympas, mais il reste a
construire une belle interface dessus - et a integrer le tout. Ce que
font les distributeurs de Linux en ce moment ...

> Cependant, la question de la perte de temps dans le modèle de
> développement libre me semble bien réelle:
> - si la réutilisation de code était massive, une erreur détectée dans
> un code source pourrait très bien s'être largement propagée, et serait
> difficile à corriger dans tous les logiciels ayant repris cette
> partie de code;

Mais tout le monde ne fait pas du copier-coller. Il y a des gens qui
prennent la peine de concevoir des APIs evolutives (pas comme ...) et
font les bibliotheques qui vont avec.

> Trop de programmeurs semblent se lancer dans un projet sans
> prendre la peine de se renseigner pour savoir ce qui a été effectué
> auparavant sur le sujet;

C'est marrant on a les memes echos en interne de certains editeurs :).

> Des efforts de standardisation tels que le LSB sont à mon avis plus que
> jamais nécessaires.

Or s'il y a un site Linux qui ne bouge pas beaucoup en ce moment,
c'est bien le site LSB.

> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
> chacune des équipes de développement, qui après avoir obtenu l'accord
> de tous, doit s'entendre avec elle pour définir un standard qui serait
> au moins un plus petit commun multiple des différentes fonctionnalités
> offertes.

D'ici la, il y aura eu quelques reussites commerciales sur la
question, quelques echecs aussi, et comme d'hab les developpeurs de
libre feront la synthese de ce qui marche pour choisir une voie.

> Ainsi, outre une facilité d'utilisation grandement accrue, cela
> permettrait à chacun de réinventer un peu moins la roue dans son coin,
> et de s'inscrire immédiatement dans un cadre cohérent.

Mais (tu connais la Debian, hein) un Linux est deja beaucoup plus
modulaire que pas mal d'autres systemes. Plutot que de vouloir tout
unifier par le haut, ce qui serait valable sur certains points et
completement premature sur d'autres, ne vaudrait-il pas mieux que les
choses continuent ainsi ?

Petit a petit les choses s'agregent, l'informatique evolue, et de
temps en temps il faut casser pour reconstruire. A mon avis il vaut
mieux continuer a casser des petits bouts (et voir comment Microsoft
s'en sortira avec son monolithe Win32 quand il faudra passer a 64
bits).

> UNIX n'a pas été conçu de façon à empêcher les utilisateurs de faire
> des choses stupides afin d'éviter de leur refuser du même coup les
> actions élégantes. -- Doug Gwyn

C'est toujours d'actu.

--
Julien Plissonneau Duquene - http://www.atlantic-line.fr/~jplissd/

[Herve Eychenne]

Stephane TOUGARD <el...@teaser.fr> wrote:

>> Lu sur slashdot:
>> "Un article du Chicago Tribune suggère que la somme d'efforts
>> déployés pour Linux serait mieux rentablilisée (en terme de temps)
>> en contribuant à l'amélioration des logiciels Microsoft.
>> L'auteur souligne que Linux est entrain de réinventer la roue.
>> Linux n'est-il pas une perte de temps ?"

> Allez, il faut mieux lire cela que d'etre aveugle.

>> - si la réutilisation de code était massive, une erreur détectée dans

>> un code source pourrait très bien s'être largement propagée, et serait
>> difficile à corriger dans tous les logiciels ayant repris cette
>> partie de code;

> Grace a l'utilisation des liens dynamiques, a la gestion du devel via

> des outils adaptes (gestion des version,...), ce type d'erreur n'est pas
> vraiment a redouter.

Sans doute. Mais pour des extractions de bouts de code (ça existe aussi),
c'est difficilement contrôlable.

>> - le développement du logiciel libre est assez anarchique. S'il est vrai
>> que tout système tend à s'auto-organiser, il n'empêche que l'entropie
>> augmente. Trop de programmeurs semblent se lancer dans un projet sans
>> prendre la peine de se renseigner pour savoir ce qui a été effectué
>> auparavant sur le sujet;

> Cela ne fait que plus de projets, plus de choix. Nous avons les moyens

> de coder dans tous les sens, notre main d'oeuvre est infinie (ou
> presque, en tout cas elle a des moyens que meme MS n'a pas).

Oui, évidemment. Mais la question est: est-ce que ça vaut toujours le
coup de coder dans tous les sens ?

>> - le logiciel libre n'a pas empêché le développement de deux bureaux
>> comparables tels que Gnome et KDE, quelles qu'en soient les causes.
>> Sans compter la duplication de toutes les G_applications et
>> K_applications correspondantes. Que l'on soit pour l'un ou pour
>> l'autre, on ne peut s'empêcher de penser à un beau gâchis et à tout le
>> temps perdu.

> Meme argument, et alors ? L'existence de Gnome ne remet pas en cause

> celle de Kde, celle de Sendmail contre Exim,... Plus de choix, du
> gachis, on s'en fout.

On peut prendre ce parti, évidemment. Mais ça me fait tout de même un
peu mal au coeur... Enfin... :-(

>> A la limite, certains pourraient parler de la concurrence
>> Linux/FreeBSD. Mais ce serait sans doute une erreur: les problèmes
>> de la licence BSD sont suffisamment importants aux yeux de certains
>> pour justifier un développement parallèle;

> Il n'y a pas de concurrence, FreeBSD existe, Linux existe et chacun

> existera tant qu'un seul individu en gardera un sur sa machine. Il n'y a
> pas de fric dans cette affaire (en tous cas, pas a ce niveau la), on ne
> peut parler de concurrence. Longue vie a Linux, FreeBSD, OpenBSD,...

C'est bien ce que je voulais dire.

>> - le polymophisme des applications est une force, mais constitue trop
>> souvent un frein, devant l'accumulation de cas particuliers dans la
>> forme, mais redondants sur le fond;

> Cela ne me gene pas et je doute que cela gene bcp de monde.

Moi non plus, d'un point de vue pratique. Mais d'un point de vue
conceptuel, ce serait vraiment très intéressant.
Eh puis, à mon avis, si ça ne manque pas à grand monde, c'est que
personne n'y a encore goûté.

>> - chacun refait tout de même un peu les mêmes choses dans son coin.
>> Par exemple, il est regrettable que les différentes distributions de
>> Linux améliorent leurs procédures d'installation en parallèle, sans
>> que les uns bénéficient directement des avancées des autres.
>> Si chacun s'était entendu sur un standard commun (de nivellement par
>> le haut, cela va de soi), que d'efforts auraient été épargnés...

> Plus il y aura de distributions, plus il y aura de supports pour porter
> Linux,

Trop de Linux différents finiraient par "tuer" Linux. Je n'ai pas dit
le faire disparaître, mais l'empêcher de tenir un jour la place qu'il
mérite.

>> Des efforts de standardisation tels que le LSB sont à mon avis plus que
>> jamais nécessaires.

> Necessaires ? pratique, oui, mais necessaires,...

Cf ci-dessus.
Au delà de ça, on pourrait dire: "pratique, donc nécessaire". ;-)

>> On assiste donc à une pseudo organisation de type fourmilière, où
>> l'ensemble de l'ouvrage finit tout de même par prendre forme, mais
>> au prix d'un déploiement d'énergie trop souvent gaspillée.

> Mais qui ne coute rien,

Ca n'est pas parce qu'une chose ne coûte rien que ça ne me gêne pas
de la voir gaspillée.

>> Dans le même ordre d'idée, quel bonheur si les applications de même
>> type fournissaient une interface standardisée (au niveau logiciel),
>> à la manière du VFS (Virtual File System) pour les systèmes de fichiers,
>> qui permettrait une modularité quasi-infinie.

> Beurk, il y en a qui preferent sendmail et d'autres qmail ou exim, et

> souvent c'est pour la maniere de configurer l'un ou l'autre que la
> preference s'etablit. La richesse est dans le choix.

Mon propos vaut plus pour les aspects de dialogue
interactif/non-interactif.

>> Ainsi, outre une facilité d'utilisation grandement accrue, cela
>> permettrait à chacun de réinventer un peu moins la roue dans son coin,
>> et de s'inscrire immédiatement dans un cadre cohérent.

> Pour un truc incoherent, Linux peut tourner sur plein d'architectures

> avec une stabilite que Windows ou MacOS ne sont meme pas capable
> d'envisager, avec un choix d'applicatifs a faire palir n'importe quel
> OS. Si Windows est plus coherent, alors que j'aime l'incoherence.

Justement. Si Linux tourne sur tant d'architectures différentes, c'est
parce que le noyau est bien agencé, puisqu'il isole les parties
dépendantes de chaque architecture (/usr/src/linux/arch/*), et que la
libc fournit une bonne couche d'abstraction.
Ces deux couches sont parmi les plus centralisées qui soient au milieu
du développement bazar de Linux, et ce n'est pas un hasard.

RV

[Herve Eychenne]

Julien Plissonneau Duquene <jpl...@abul.org> wrote:

>> L'auteur souligne que Linux est entrain de réinventer la roue.

> Il a rate le fait que ce coup ci le but est d'inventer la roue une
> bonne fois pour toutes.

:-)

>> Pas un de leurs systèmes d'exploitation successifs n'a jamais valu le
>> moindre centime.

> Je ne suis pas d'accord. Le noyau NT aurait pu etre interessant, mais

> ces sagouins n'ont pas daigne documenter ses appels systeme.
> Effectivement, le reste n'est pas terrible ...

J'ai dit que je ne ferais sans doute plus la même réponse aujourd'hui.
A l'époque, NT4 venait tout juste de sortir.
Cela dit, je maintiens quand même ce point: le noyau NT a tout de même
de graves problèmes (notamment au niveau de la pile réseau), et tu le
sais bien.

>> - il est moins que certain que le fait de mettre son talent
>> bénévolement au service d'une firme aussi mercantile que Microsoft
>> entousiasme les développeurs de Linux;

> Pas si sur (cf Wine, Cygnus, djgpp, Apache/win32). Mais c'est vrai que

> travailler avec des systemes documentes et dont on dispose du code
> source, c'est plus motivant, ne serait-ce qu'en reduisant le temps
> passe a faire des hypotheses sur le fonctionnement d'un appel systeme.

Oui, en effet. Si je peux arriver (difficilement) à comprendre
les motivations de ces gens, il me semble qu'ils sont tout de même
dans l'erreur. Je partage l'avis de Stallman sur ce point.
Le raisonnement des gens qui développent du logiciel libre sur un système
propriétaire est biaisé dès le départ (un peu comme les développeurs
de KDE qui ont commencé à fournir du code GPL basé sur une bibliothèque
non libre).

>> Pour ce qui est du logiciel libre:

>> - le temps n'est pas la préoccupation principale. C'est la qualité du
>> produit fini qui compte.

> Je ne crois pas qu'on puisse parler de produit fini dans le cadre du
> LL.

Très juste. C'est une erreur d'avoir employé ce terme.

> En general on dispose plutot d'outils sympas, mais il reste a
> construire une belle interface dessus - et a integrer le tout. Ce que
> font les distributeurs de Linux en ce moment ...

Le rôle des "distributeurs" est limité. Ils assemblent des composants
indépendants les uns des autres. S'ils développent des outils, c'est
en immense majorité en rapport avec l'installation et la maintenance,
rien de plus. Ce n'est pas suffisant.

>> Cependant, la question de la perte de temps dans le modèle de
>> développement libre me semble bien réelle:
>> - si la réutilisation de code était massive, une erreur détectée dans
>> un code source pourrait très bien s'être largement propagée, et serait
>> difficile à corriger dans tous les logiciels ayant repris cette
>> partie de code;

> Mais tout le monde ne fait pas du copier-coller.

C'est parfois un tort. Mais tant mieux aussi.

> Il y a des gens qui prennent la peine de concevoir des APIs
> evolutives (pas comme ...) et font les bibliotheques qui vont avec.

Heureusement.

>> Des efforts de standardisation tels que le LSB sont à mon avis plus que
>> jamais nécessaires.

> Or s'il y a un site Linux qui ne bouge pas beaucoup en ce moment,

> c'est bien le site LSB.

Eh oui. :-((

>> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
>> chacune des équipes de développement, qui après avoir obtenu l'accord
>> de tous, doit s'entendre avec elle pour définir un standard qui serait
>> au moins un plus petit commun multiple des différentes fonctionnalités
>> offertes.

> D'ici la, il y aura eu quelques reussites commerciales sur la
> question,

?? Comment une telle démarche pourrait-elle venir d'une entreprise ?

> quelques echecs aussi, et comme d'hab les developpeurs de
> libre feront la synthese de ce qui marche pour choisir une voie.

Tout ce qui peut venir d'une entreprise commercial dans ce domaine,
c'est le succès de masse d'un logiciel, dont le type de développement
serait ouvert et réutilisable, conduisant à un standard de fait.
Je ne vois pas à l'heure actuelle comment cela pourrait arriver...

>> Ainsi, outre une facilité d'utilisation grandement accrue, cela
>> permettrait à chacun de réinventer un peu moins la roue dans son coin,
>> et de s'inscrire immédiatement dans un cadre cohérent.

> Mais (tu connais la Debian, hein) un Linux est deja beaucoup plus

> modulaire que pas mal d'autres systemes.

Oui, et alors ? Ca n'est pas de nature à me consoler. ;-)
La "misère" des autres ne me fait pas oublier la mienne, même si elle
est moins grande.

> Plutot que de vouloir tout unifier par le haut,

Mais l'idéal est de le faire par le bas, et dès le début !
Seulement, il y a une base installée, et on ne peut souvent le faire
que par le haut, à l'heure qu'il est.

> ce qui serait valable sur certains points et completement premature
> sur d'autres, ne vaudrait-il pas mieux que les choses continuent
> ainsi ?

Dans un sens, peut-être, mais uniquement si les choses ne dégénèrent
pas. Or, bien malin qui pourrait le dire. Alors dans le doute, il vaut
sans doute mieux parer au plus pressé.

> Petit a petit les choses s'agregent, l'informatique evolue, et de
> temps en temps il faut casser pour reconstruire. A mon avis il vaut
> mieux continuer a casser des petits bouts (et voir comment Microsoft
> s'en sortira avec son monolithe Win32 quand il faudra passer a 64
> bits).

Microsoft a maintenant les moyens de tout casser pour reconstruire.
Pour le logiciel libre, c'est infiniment plus difficile, et de toute
manière, c'est sur une échelle limitée.

RV

[dru...@multimania.com]

[...]

> Il a rate le fait que ce coup ci le but est d'inventer la roue une
> bonne fois pour toutes.
>

Plus de 15 ans que je fais de l'info et regulierement (tous les 6 mois / 1 an)
quelqu'un se pointe en pretendant avoir trouve _LE_ truc qui mettra fin a tous
nos problemes.

Parfois le truc en question sort, et on se rend compte que c'est pas au point,
ou alors que ca resoud bien quelques problemes, mais pour en rajouter un tas
d'autres derriere.

Parfois aussi ca sort pas, ou c'est la resucee d'un truc vieux comme le monde
(comme le NC de Larry "que de la gueule" Ellison)

En general, l'idee fait son chemin, et se fait une petite place, a cote de
l'existant. La revolution annoncee se transforme en evolution.

A+

Denis
--
Rome did not create a great empire by having meetings, they did it by killing
all those who opposed them.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

[Pablo Saratxaga]

Kaixo!
on 26 Apr 1999 03:49:26 GMT,
Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> said:

HE> Lu sur slashdot:
HE> "Un article du Chicago Tribune suggère que la somme d'efforts
HE> déployés pour Linux serait mieux rentablilisée (en terme de temps)

Lis la signature du type qui a pondu l'article, il travaille pour Microsoft,
et pour le project "Money" qui plus est.
C'est à dire que non seulement il est fort probable que ce qu'il dit
soit partisan, voire du FUD comandé par son employeur; mais en plus il
fait exactemment ce qu'il reproche: reinventer la roue; sauf que, comme
Microsoft ne produit pas du code libre, ce qu'il fait ne profite à personne
(sauf aux actionnaires de MS); tandis que la duplication de code du libre
profite au contraire à tout le monde; tout le monde pouvant recuperer pour
son projet le code ainsi produit.

HE> Cependant, la question de la perte de temps dans le modèle de
HE> développement libre me semble bien réelle:

Ne te laisse pas embobiner par leur wishful thinking.
Regarde avec tes propres yeux plutôt: le developpement des projets libres
me semble au contraire bcp plus rapide et plus fort qu'il y a quelques
années; regarde des projets comme le GIMP, la bibliothèque GTK+, KDE,
Gnome,... ils ont tous moins de 3 ans si je ne me trompe; tu appelles ça une
perte de temps ? Connais-tu un seul exemple dans le non-libre où dans un
pareil laps de temps on aie crée des logiciels equivalents, à partir de zero ?

HE> - le logiciel libre n'a pas empêché le développement de deux bureaux
HE> comparables tels que Gnome et KDE,

Ni de vi et emacs, ni de tin et gnus, ni d'une miryade de WM,...
les gens ont besoin de diversité pour s'épanouir.

HE> Sans compter la duplication de toutes les G_applications et
HE> K_applications correspondantes. Que l'on soit pour l'un ou pour
HE> l'autre, on ne peut s'empêcher de penser à un beau gâchis et à tout le
HE> temps perdu.

Je ne vois là aucun gâchis ni aucun temps perdu !
Chacun est libre de faire ce qu'il veut et de participer au projet qu'il veut.

HE> A la limite, certains pourraient parler de la concurrence
HE> Linux/FreeBSD. Mais ce serait sans doute une erreur: les problèmes
HE> de la licence BSD sont suffisamment importants aux yeux de certains
HE> pour justifier un développement parallèle;

Il n'y a pas que la licence; il y a aussi que FreeBSD est un BSD, Linux non.
Pour certains ça a de l'importance, et justifie pleinement l'existence des
deux.

HE> - chacun refait tout de même un peu les mêmes choses dans son coin.

Et alors ?

HE> Par exemple, il est regrettable que les différentes distributions de
HE> Linux améliorent leurs procédures d'installation en parallèle, sans
HE> que les uns bénéficient directement des avancées des autres.
HE> Si chacun s'était entendu sur un standard commun (de nivellement par
HE> le haut, cela va de soi), que d'efforts auraient été épargnés...

Propose un standard. S'il est bon il sera suivi.

HE> On assiste donc à une pseudo organisation de type fourmilière, où
HE> l'ensemble de l'ouvrage finit tout de même par prendre forme, mais
HE> au prix d'un déploiement d'énergie trop souvent gaspillée.

Mais avec un capital d'adaptibilité énorme.
Il n'est pas bon d'être hyper-specialisé; c'est l'extinction assurée au
moindre changement de l'environnement.

HE> Il est donc capital de fournir des modèles réutilisables, à tous les
HE> niveaux possibles. Ainsi, toute application devrait être conçue de bas
HE> en haut. A savoir: fournir une bibliothèque de fonctions non
HE> interactives, au-dessus de laquelle seraient bâties les interfaces
HE> texte et graphique, avec un dialogue entre les deux niveaux, selon un
HE> protocole bien défini. A l'extrême, il serait ainsi possible
HE> d'intervenir dans une application graphique au moyen d'un simple
HE> script shell, par exemple.
HE> De même, la configuration d'une application devrait pouvoir se faire
HE> tant en mode texte, en éditant un fichier de configuration
HE> intelligible, qu'en mode graphique, par l'intermédiaire d'une
HE> application qui lirait ce même fichier de configuration et le
HE> modifierait, sans écraser les modifications faites à la main comme on
HE> le voit trop souvent !

Tu ne dois pas suivre l'évolution recente pour dire ça; car sinon tu
verrais que c'est ce qui se passe; seulement ça se fait par évolution
naturelle, c'est sans doute plus lent et cahotique; mais plus fiable
et donne de meilleurs résultats au final.

HE> Dans le même ordre d'idée, quel bonheur si les applications de même
HE> type fournissaient une interface standardisée (au niveau logiciel),
HE> à la manière du VFS (Virtual File System) pour les systèmes de fichiers,
HE> qui permettrait une modularité quasi-infinie.
HE> Par exemple, il deviendrait ainsi possible de commander le déplacement
HE> d'un fenêtre de manière non-interactive, ou de la changer d'écran
HE> virtuel d'une façon unique, sans ce soucier de savoir s'il on utilise
HE> AfterStep, WindowMaker, Fvwm, ou tout autre gestionnaire de fenêtre.

HE> S'il est vrai que le modèle "Bazar" possède de grandes forces,
HE> l'absence d'un architecte garantissant une cohérence d'ensemble se
HE> fait parfois cruellement sentir.

Laisser le temps au temps.
Ca fait à peine quelques mois que les totues premières versions balbutientes
de programmes libres utilisant CORBA comme caracteristique princiapel ont
vu le jour, et tu voudrais tout avoir tout de suite :)

HE> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
HE> chacune des équipes de développement,

JAMAIS !

Forcer les developpeurs à coder des choses qu'ils ne veulent pas c'est
la fin du libre, j'espère que tu en est conscient.

L'initiative viendra des developpeurs qui trouveront l'idée bonne; ou des
theoriciens qui retrousseront leurs manches.

--
À bientôt,
Pablo Saratxaga PGP Key available, key ID: 0x8F0E4975

http://www.ping.be/~pin19314/

[Herve Eychenne]

Pablo Saratxaga <sr...@chanae.alphanet.ch> wrote:

> HE> Lu sur slashdot:
> HE> "Un article du Chicago Tribune suggère que la somme d'efforts
> HE> déployés pour Linux serait mieux rentablilisée (en terme de temps)

> Lis la signature du type qui a pondu l'article, il travaille pour Microsoft,
> et pour le project "Money" qui plus est.
> C'est à dire que non seulement il est fort probable que ce qu'il dit
> soit partisan, voire du FUD comandé par son employeur;

Intéressante précision, même s'il on en n'avait nul besoin pour réfuter
l'article en bloc.

> HE> Cependant, la question de la perte de temps dans le modèle de
> HE> développement libre me semble bien réelle:

> Ne te laisse pas embobiner par leur wishful thinking.

Ce n'est pas trop mon style... ;-)
Cela dit, il m'a semblé que l'article (qui en lui-même n'est qu'un
FUD de plus) pouvait servir de base à une réflexion sur le logiciel
libre (et Linux en particulier).

> Regarde avec tes propres yeux plutôt: le developpement des projets
> libres me semble au contraire bcp plus rapide et plus fort qu'il y a
> quelques années; regarde des projets comme le GIMP, la bibliothèque
> GTK+, KDE, Gnome,... ils ont tous moins de 3 ans si je ne me trompe;
> tu appelles ça une perte de temps ? Connais-tu un seul exemple dans
> le non-libre où dans un pareil laps de temps on aie crée des
> logiciels equivalents, à partir de zero ?

Bien sûr que le développement est ultra-rapide ! Mais à mon avis, c'est
en partie dû au grand accroissement des effectifs (couplé à "l'effet de
mode" Linux). Cela ne veut pas dire qu'un temps non négligeable n'est
pas gaspillé (même si on ne le voit pas directement, puisque seule la
partie émergée de l'iceberg est visible).
Mais bon, une fois encore, je reconnais que l'argument du temps n'est
pas un point central en matière de logiciel libre.

> HE> - le logiciel libre n'a pas empêché le développement de deux bureaux
> HE> comparables tels que Gnome et KDE,

> Ni de vi et emacs, ni de tin et gnus, ni d'une miryade de WM,...
> les gens ont besoin de diversité pour s'épanouir.

Le nombre de "Evidemment" que m'inspire les diverses remarques commencent
à me faire croire que j'ai été mal compris. ;-)
Il ne s'agit pas de remettre en cause la liberté de chacun, mais de
fournir un cadre de travail qui bénéficierait à tout le monde, même si
personne n'était obligé de le suivre (que d'évidences...).

> HE> Sans compter la duplication de toutes les G_applications et
> HE> K_applications correspondantes. Que l'on soit pour l'un ou pour
> HE> l'autre, on ne peut s'empêcher de penser à un beau gâchis et à tout le
> HE> temps perdu.

> Je ne vois là aucun gâchis ni aucun temps perdu !

!! Ah... Faire la même chose deux fois, l'une avec Qt, l'autre avec
Gtk, ce n'est pas du temps perdu ?

> HE> - chacun refait tout de même un peu les mêmes choses dans son coin.

> Et alors ?

Et alors, il y a suffisamment de choses non encore effectuées pour que le
talent des programmeurs qui bossent simultanément sur des projets quasi-
identiques soit mieux réparti.

> HE> Il est donc capital de fournir des modèles réutilisables, à tous les
> HE> niveaux possibles. Ainsi, toute application devrait être conçue de bas
> HE> en haut. A savoir: fournir une bibliothèque de fonctions non
> HE> interactives, au-dessus de laquelle seraient bâties les interfaces
> HE> texte et graphique, avec un dialogue entre les deux niveaux, selon un
> HE> protocole bien défini. A l'extrême, il serait ainsi possible
> HE> d'intervenir dans une application graphique au moyen d'un simple
> HE> script shell, par exemple.
> HE> De même, la configuration d'une application devrait pouvoir se faire
> HE> tant en mode texte, en éditant un fichier de configuration
> HE> intelligible, qu'en mode graphique, par l'intermédiaire d'une
> HE> application qui lirait ce même fichier de configuration et le
> HE> modifierait, sans écraser les modifications faites à la main comme on
> HE> le voit trop souvent !

> Tu ne dois pas suivre l'évolution recente pour dire ça;

J'essaye. Mais c'est dur de s'accrocher, tellement ça va vite, je l'avoue.

> car sinon tu verrais que c'est ce qui se passe;

Tant mieux ! Cite-moi un logiciel libre qui soit conforme à tous les
critères que j'énonçais plus haut.
Je ne demande qu'à te croire.

> HE> Dans le même ordre d'idée, quel bonheur si les applications de même
> HE> type fournissaient une interface standardisée (au niveau logiciel),
> HE> à la manière du VFS (Virtual File System) pour les systèmes de fichiers,
> HE> qui permettrait une modularité quasi-infinie.
> HE> Par exemple, il deviendrait ainsi possible de commander le déplacement
> HE> d'un fenêtre de manière non-interactive, ou de la changer d'écran
> HE> virtuel d'une façon unique, sans ce soucier de savoir s'il on utilise
> HE> AfterStep, WindowMaker, Fvwm, ou tout autre gestionnaire de fenêtre.

> HE> S'il est vrai que le modèle "Bazar" possède de grandes forces,
> HE> l'absence d'un architecte garantissant une cohérence d'ensemble se
> HE> fait parfois cruellement sentir.

> Laisser le temps au temps.
> Ca fait à peine quelques mois que les totues premières versions
> balbutientes de programmes libres utilisant CORBA comme
> caracteristique princiapel ont vu le jour, et tu voudrais tout avoir
> tout de suite :)

Ben oui, je suis d'un naturel impatient (visionnaire, ça ferait un peu
prétentieux). ;-)

> HE> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
> HE> chacune des équipes de développement,

> JAMAIS !

> Forcer les developpeurs à coder des choses qu'ils ne veulent pas c'est
> la fin du libre, j'espère que tu en est conscient.

> L'initiative viendra des developpeurs qui trouveront l'idée bonne; ou des
> theoriciens qui retrousseront leurs manches.

Ca y est, j'en ai la confirmation: tu as mal lu (et en plus tu as
tronqué ma phrase pour mieux t'en convaincre).
Je persiste. Prenons un exemple, ça passe toujours mieux.
Tiens... les gestionnaires de fenêtre.
Pour dégager une interface (non visuelle) commune à Windowmaker,
AfterStep, Fvwm et les autres, tu crois que l'idée peut germer des
développeurs des ces derniers ? Ca m'étonnerait franchement.
Ils sont chacun bien trop centrés (et c'est tout à fait logique) sur
leurs applications respectives.
Quelqu'un d'extérieur à ces équipes peut proposer un changement par le
haut (puisqu'un changement pas le bas est exclu vu le degré d'avancement).
Il prend contact avec chacune des équipes, discute du bien-fondé de la
chose, et négocie.
Si le projet semble bon, il sera vraisemblablement adopté, tu le dis
toi-même. Sinon, tant pis.

RV

[Jerome ALET]

Herve Eychenne wrote:
> Cependant, la question de la perte de temps dans le modèle de
> développement libre me semble bien réelle:

le phenomene des logiciels libres n'est ni plus ni moins qu'une
reproduction a petite (tres petite :-) echelle de ce que Mere Nature
fait depuis longtemps: seuls les meilleurs survivent, et il y a un sacre
gachis, et en temps, et en etres vivants.

Si l'on considere que la boite de RonRon est le summum de ce qui peut
exister, il a quand meme fallu environ 15 milliards d'annees et des
brouettes pour qu'elle naisse. Mais quel resultat !

Ne soyons pas presses, dans 100 ans les logiciels ne seront peut etre
plus qu'un mauvais souvenir...

mes 2 eurocents ;-)

--
Jerome ALET - al...@unice.fr - http://cortex.unice.fr/~jerome
Faculte de Medecine de Nice - http://noe.unice.fr - Tel: 04 93 37 76 30
28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE

[Julien Plissonneau Duquene]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:

> Cela dit, je maintiens quand même ce point: le noyau NT a tout de même
> de graves problèmes (notamment au niveau de la pile réseau), et tu le
> sais bien.

Oui, il a des problemes. Mais techniquement, il n'est pas
ininteressant. Par exemple, il utilise lui aussi quelque chose qui
ressemble au VFS (mais qui est malheureusement quasi-inaccessible via
Win32). Il y a aussi le fait qu'on puisse facilement creer des chaines
de pilotes, ce qui n'est pas toujours evident avec Linux.

Si MS voulait jouer une strategie a plus long terme que la publication
de tests truques, ils rendraient _vraiment_ open source le noyau NT,
pour le fiabiliser. Et il y aurait des gens pour bosser dessus (dont
moi, pour ecrire une emulation de NaTive API sous Linux).

> Oui, en effet. Si je peux arriver (difficilement) à comprendre
> les motivations de ces gens, il me semble qu'ils sont tout de même
> dans l'erreur. Je partage l'avis de Stallman sur ce point.

Je ne crois pas qu'il faille etre aussi categorique. La recherche
informatique (universitaire et autres) innove beaucoup, mais la
diffusion des innovations reste confidentielle, faute de marketing. Le
LL, lui, reprend de plus en plus les recettes qui marchent dans les
softs commerciaux. Il y a un stade ou les logiciels commerciaux aident
a diffuser l'innovation, grace au marketing (c'est aussi ca les jolies
interfaces son et image) - et parfois a grand renforts d'arguments
bidon.

> Le raisonnement des gens qui développent du logiciel libre sur un système
> propriétaire est biaisé dès le départ (un peu comme les développeurs
> de KDE qui ont commencé à fournir du code GPL basé sur une bibliothèque
> non libre).

Alors jette ta carte mere dont tu n'as surement pas le centieme des
specifications, dessoude la puce de BIOS qu'il y a dessus, reecrit le
microcode de tes disques durs ... et change de microprocesseur.

> > Plutot que de vouloir tout unifier par le haut,
>
> Mais l'idéal est de le faire par le bas, et dès le début !
> Seulement, il y a une base installée, et on ne peut souvent le faire
> que par le haut, à l'heure qu'il est.

C'est pour ca que je dis que c'est premature. Il faudrait consacrer
des efforts de formation enormes sur des standards ... a definir.

Un des aspects importants du succes de Linux est son interoperabilite
avec les systemes du marche. Autant profiter de ces standards pour
ecrire des programmes qui marchent, et laisser ceux qui savent
developper les futurs standards qui marcheront mieux. C'est bien, les
alternatives.

> > Petit a petit les choses s'agregent, l'informatique evolue, et de
> > temps en temps il faut casser pour reconstruire. A mon avis il vaut
> > mieux continuer a casser des petits bouts (et voir comment Microsoft
> > s'en sortira avec son monolithe Win32 quand il faudra passer a 64
> > bits).
>
> Microsoft a maintenant les moyens de tout casser pour reconstruire.

Ils vont faire leur OS 64 bits, et demander a une boite d'ecrire
l'emulation 32 bits, qui elle meme fait tourner une couche 16 bits,
avec des bouts de 8 bits dedans, etc etc ...

Deja quand je vois certains softs que j'installe, soi-disant 32 bits,
qui chargent des DLL 16 bits et font appel a des fonctions DOS ...

> Pour le logiciel libre, c'est infiniment plus difficile, et de toute
> manière, c'est sur une échelle limitée.

Bien pour ca qu'il faut que l'evolution soit plus continue. Il faut de
la perennite, et pour ca il faut que tout le monde se mette d'accord
sur la bonne maniere d'ecrire les programmes. Ca prend beaucoup de
temps.

[Herve Eychenne]

Julien Plissonneau Duquene <jpl...@abul.org> wrote:

> Si MS voulait jouer une strategie a plus long terme que la publication
> de tests truques, ils rendraient _vraiment_ open source le noyau NT,
> pour le fiabiliser. Et il y aurait des gens pour bosser dessus (dont
> moi, pour ecrire une emulation de NaTive API sous Linux).

Mais pourquoi es-tu donc à toutes forces attaché à ce noyau NT ?
Il est vrai qu'il y a quelques concepts intéressants. Mais Windows
NT est tellement monolithique (comparé à ce qu'il aurait pu être)
qu'il faut voir le tout dans son ensemble: et le tout est difficilement
récupérable.

>> Oui, en effet. Si je peux arriver (difficilement) à comprendre
>> les motivations de ces gens, il me semble qu'ils sont tout de même
>> dans l'erreur. Je partage l'avis de Stallman sur ce point.

> Je ne crois pas qu'il faille etre aussi categorique. La recherche

> informatique (universitaire et autres) innove beaucoup, mais la
> diffusion des innovations reste confidentielle, faute de marketing. Le
> LL, lui, reprend de plus en plus les recettes qui marchent dans les
> softs commerciaux. Il y a un stade ou les logiciels commerciaux aident
> a diffuser l'innovation, grace au marketing (c'est aussi ca les jolies
> interfaces son et image) - et parfois a grand renforts d'arguments
> bidon.

Mais en quoi les logiciels commerciaux ne serait-ils pas libres ?
(je n'ai pas dit sous GPL) Ils bénéficieraient de tout autant de
marketing, si ce n'est plus en ce moment, vu l'effet de mode actuel.

>> Le raisonnement des gens qui développent du logiciel libre sur un système
>> propriétaire est biaisé dès le départ (un peu comme les développeurs
>> de KDE qui ont commencé à fournir du code GPL basé sur une bibliothèque
>> non libre).

> Alors jette ta carte mere dont tu n'as surement pas le centieme des

> specifications, dessoude la puce de BIOS qu'il y a dessus, reecrit le
> microcode de tes disques durs ... et change de microprocesseur.

Oui. Je vais m'acheter un Alpha sous peu.
Quitte à utiliser du hard propriétaire (c'est aussi un problème à mon
sens), autant utiliser le meilleur rapport puissance/prix.

>> > Plutot que de vouloir tout unifier par le haut,

>> Mais l'idéal est de le faire par le bas, et dès le début !
>> Seulement, il y a une base installée, et on ne peut souvent le faire
>> que par le haut, à l'heure qu'il est.

> C'est pour ca que je dis que c'est premature.

Ce n'est pas prématuré, c'est trop tard. ;-)

> Il faudrait consacrer des efforts de formation enormes sur des
> standards ... a definir.

Mais je ne vois pas ce qu'une telle "formation" (le mot est trop formel
à mon goût) a de pire que la formation qu'acquièrent chaque jour
les développeurs sur des tas d'autres sujets (programmation C, Gtk,
etc...).

> Un des aspects importants du succes de Linux est son interoperabilite
> avec les systemes du marche. Autant profiter de ces standards pour
> ecrire des programmes qui marchent, et laisser ceux qui savent
> developper les futurs standards qui marcheront mieux. C'est bien, les
> alternatives.

Cela se passe actuellement comme ça, et je ne vois pas pourquoi cela
changerait. Pourquoi faudrait-il toujours le logiciel libre soit à
la traîne ?

>> > Petit a petit les choses s'agregent, l'informatique evolue, et de
>> > temps en temps il faut casser pour reconstruire. A mon avis il vaut
>> > mieux continuer a casser des petits bouts (et voir comment Microsoft
>> > s'en sortira avec son monolithe Win32 quand il faudra passer a 64
>> > bits).

>> Microsoft a maintenant les moyens de tout casser pour reconstruire.

> Ils vont faire leur OS 64 bits, et demander a une boite d'ecrire

> l'emulation 32 bits, qui elle meme fait tourner une couche 16 bits,
> avec des bouts de 8 bits dedans, etc etc ...

Quand je dis que Microsoft a maintenant les moyens de tout casser pour
reconstruire, je sais bien que jusqu'à présent, ils détiennent le record
de couches bancales pour assurer une médiocre compatibilité avec
l'existant.

> Deja quand je vois certains softs que j'installe, soi-disant 32 bits,
> qui chargent des DLL 16 bits et font appel a des fonctions DOS ...

Oui. Il n'empêche que s'ils voulaient tout refaire, leur puissance
est devenue telle que beaucoup de gens les suivraient (ou ne pourraient
faire vraiment autrement que de les suivre). Plus pour longtemps,
espérons.

>> Pour le logiciel libre, c'est infiniment plus difficile, et de toute
>> manière, c'est sur une échelle limitée.

> Bien pour ca qu'il faut que l'evolution soit plus continue. Il faut de

> la perennite, et pour ca il faut que tout le monde se mette d'accord
> sur la bonne maniere d'ecrire les programmes. Ca prend beaucoup de
> temps.

Nous sommes d'accord.
Une bonne évolution est aussi faite de rupture. Comme le disait fort
justement Jérôme Alet, l'évolution des logiciels libres ressemble à
l'évolution des êtres vivants. A ceci près que l'évolution de ces
derniers a été aussi bien faite d'évolutions continues que de ruptures.
Le logiciel libre est difficilement capable de rompre avec l'existant.
Une rupture, c'est douloureux, ça ne fait pas plaisir à grand monde,
même quand c'est justifié. Si on doit attendre la prochaine rupture,
ça risque de prendre pas mal de temps, en effet !

[Carsten Laekamp]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:

> Bien sûr que le développement est ultra-rapide ! Mais à mon avis, c'est
> en partie dû au grand accroissement des effectifs (couplé à "l'effet de
> mode" Linux). Cela ne veut pas dire qu'un temps non négligeable n'est
> pas gaspillé (même si on ne le voit pas directement, puisque seule la
> partie émergée de l'iceberg est visible).

Est-ce dû à l'accroissement ou à l'importance des effectifs ? ( Il est
clair que ce modèle ne serait pas fonctionnel avec des effectifs
réduits. )

D'un autre côté, la perte n'est pas si grande, puisque jamais deux
produits similaires ne sont identiques. L'utilisateur a par conséquent
le *choix*. Si on voulait créer un système hyper-cohérent,
hyper-structuré, hyper-centralisé, on perdrait en richesse et on
augmenterait, par la force des choses, l'effort à fournir en termes
d'organisation, d'intégration, etc... y gagnerait-on, en termes de
"ressources humaines" (je déteste cette expression) ? Sans compter que
beaucoup de petits développeurs ne seraient plus prêts à travailler
(gratuitement) dans la structure très hiérarchisée qui s'imposerait.

En regardant de près, la situation est la même pour les logiciels
commerciaux dont le développement est plus "classique". Comptez le
nombre de logiciels concurrents. Evidemment, ils ne font pas partie
d'un même projet mais ceci est aussi vrai en ce qui concerne
linux (ou n'importe quel autre ensemble OS/applicatifs libre).

D'ailleurs, pour en revenir à l'article cité en début d'enfilade,
l'argumentation de ce dernier est plus que douteuse. Elle repose sur
l'idée, fausse, que Windows est l'OS standard, reconnu par tous et la
propriété de tous, et non un produit dans un marché
concurrentiel. L'apologie du monopole au détriment de l'économie de
marché. C'était assez incompréhensible jusqu'aux précisions de Pablo
sur l'origine de l'auteur (merci !). On comprend mieux maintenant.

Je voudrais d'ailleurs retourner l'argument à Microsoft: pourquoi avoir
gaspillé des ressources pour créer Windows au lieu de contribuer à MacOS
? (Apple l'a échappé belle ! :) ). Pourquoi MSIE, au lieu de soutenir
le standard, un vrai standard de fait, cette fois: Netscape ?

Je me demande ce que l'économiste occidental moyen répondrait à cela ;)

> !! Ah... Faire la même chose deux fois, l'une avec Qt, l'autre avec
> Gtk, ce n'est pas du temps perdu ?

Oui. Mais ce n'est pas un problème "sociologique" mais de méthode de
programmation. Des logiciels plus modulaires permettraient de
contourner ce problème, comme tu l'avais précisé auparavant. Mais
_pas_ dans le cadre d'un projet structuré, plutôt par le choix des
développeurs (qui auraient tout intérêt à le faire,
d'ailleurs). Heureux effet secondaire: on aurait moins de guerres de
religion du style KDE/gnome, qui ne sont que stériles, après un
certain temps.

--
Carsten Läkamp
carsten...@wanadoo.fr

[Herve Eychenne]

Carsten Laekamp <carsten...@wanadoo.fr> wrote:

>> Bien sûr que le développement est ultra-rapide ! Mais à mon avis, c'est
>> en partie dû au grand accroissement des effectifs (couplé à "l'effet de
>> mode" Linux). Cela ne veut pas dire qu'un temps non négligeable n'est
>> pas gaspillé (même si on ne le voit pas directement, puisque seule la
>> partie émergée de l'iceberg est visible).

> Est-ce dû à l'accroissement ou à l'importance des effectifs ?

Oui, tout de même, je pense...

> ( Il est clair que ce modèle ne serait pas fonctionnel avec des
> effectifs réduits. )

Le logiciel libre ne date pas d'hier.
Et pourtant il a tourné plutôt bien avec des effectifs plus réduits
qu'aujourd'hui... Seulement, ça partait peut-être un peu moins dans
tous les sens (ce n'est pas une critique, mais un constat).

> D'un autre côté, la perte n'est pas si grande, puisque jamais deux
> produits similaires ne sont identiques.

Bon, on ne va pas commencer à polémiquer sur le degré d'identité entre
deux logiciels. Pour moi, il est clair que chaque type de logiciel
a ses grandes orientations incontournables. C'est là-dessus qu'il
faudrait travailler.

> L'utilisateur a par conséquent le *choix*. Si on voulait créer un
> système hyper-cohérent, hyper-structuré, hyper-centralisé,

Pour ce qui est d'hyper-centraliser, ce n'est pas vraiment souhaitable.
Disons qu'il faudrait qu'un bon modèle s'impose et que tout ceux qui
sont persuadés que c'est une bonne façon de suivre le suivent.

> on perdrait en richesse

Je ne vois pas en quoi... Personne ne serait obligé de suivre le
modèle. Il ne triompherait que si (parce qu') il est bon.

> et on augmenterait, par la force des choses, l'effort à fournir en
> termes d'organisation, d'intégration, etc...

On n'a rien sans rien, malheureusement. Mais il ne faut pas surestimer
la charge de travail en la matière.

> y gagnerait-on, en termes de "ressources humaines" (je déteste cette
> expression) ?

On ne peut pas dire que je l'aime beaucoup non plus. ;-)
Quand on a une bonne architecture générale, on gagne en temps de
développement ce qu'on perd un peu en gestion.

> Sans compter que beaucoup de petits développeurs ne seraient plus
> prêts à travailler (gratuitement) dans la structure très
> hiérarchisée qui s'imposerait.

On dérive, là ! Il ne s'agirait nullement de copier le modèle
cathédrale, mais d'organiser de petites cathédrales pleines de bazar
aux bons endroits.
C'est déjà le cas pour le noyau, la libc, et X. De belles réussites.
Il faudrait peut-être s'en inspirer (à plus petite échelle) dans des
parties de code de plus haut niveau.

> [...]

>> !! Ah... Faire la même chose deux fois, l'une avec Qt, l'autre avec
>> Gtk, ce n'est pas du temps perdu ?

> Oui. Mais ce n'est pas un problème "sociologique" mais de méthode de

> programmation. Des logiciels plus modulaires permettraient de
> contourner ce problème, comme tu l'avais précisé auparavant. Mais
> _pas_ dans le cadre d'un projet structuré, plutôt par le choix des
> développeurs (qui auraient tout intérêt à le faire, d'ailleurs).

Mais rien ne peut se faire sans les développeurs. Pas question de leur
imposer quoique ce soit. Juste proposer.

> Heureux effet secondaire: on aurait moins de guerres de religion du
> style KDE/gnome, qui ne sont que stériles, après un certain temps.

Oui, d'ailleurs on a sans doute atteint la limite. Ca se voit d'ailleurs;
il y a moins de guerres KDE/Gnome ces temps-ci.

[Carsten Laekamp]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:

> Carsten Laekamp <carsten...@wanadoo.fr> wrote:

>
> Le logiciel libre ne date pas d'hier.
> Et pourtant il a tourné plutôt bien avec des effectifs plus réduits
> qu'aujourd'hui... Seulement, ça partait peut-être un peu moins dans
> tous les sens (ce n'est pas une critique, mais un constat).

Oui. Quand je parlais de "ce modèle", je parlais de ce que tu appelais
"polymorphisme", pas du logiciel libre. Je trouve d'ailleurs étonnant
que ni les produits de la FSF (enfin, une grande partie d'entre eux)
ni XFree n'aient de concurrents libres. Une preuve de leur qualité.

> > Pour ce qui est d'hyper-centraliser, ce n'est pas vraiment souhaitable.
> Disons qu'il faudrait qu'un bon modèle s'impose et que tout ceux qui
> sont persuadés que c'est une bonne façon de suivre le suivent.
>
> > on perdrait en richesse
>
> Je ne vois pas en quoi... Personne ne serait obligé de suivre le
> modèle. Il ne triompherait que si (parce qu') il est bon.

Peut-être n'y a-t-il pas encore simplement ce modèle idéal , pour une
grande partie des applications ? ;) D'autre part, si tout le monde se
conformait à un modèle unique, on perdrait en créativité.

>
> > Sans compter que beaucoup de petits développeurs ne seraient plus
> > prêts à travailler (gratuitement) dans la structure très
> > hiérarchisée qui s'imposerait.
>
> On dérive, là ! Il ne s'agirait nullement de copier le modèle
> cathédrale, mais d'organiser de petites cathédrales pleines de bazar
> aux bons endroits.
> C'est déjà le cas pour le noyau, la libc, et X. De belles réussites.
> Il faudrait peut-être s'en inspirer (à plus petite échelle) dans des
> parties de code de plus haut niveau.

Mais on a déjà plein de petites cathédrales. Une grande partie de la
redondance vient du fait que certaines d'entre elles se font
concurrence (voir les différents *BSD, gnome et KDE, pine et mutt,
entre autres exemples). Le modèle unique impose la cathédrale unique.

Ciao,

--
Carsten Läkamp
carsten...@wanadoo.fr

[Julien Plissonneau Duquene]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:

> Il est vrai qu'il y a quelques concepts intéressants. Mais Windows
> NT est tellement monolithique (comparé à ce qu'il aurait pu être)
> qu'il faut voir le tout dans son ensemble: et le tout est difficilement
> récupérable.

Mais je ne suis pas d'accord ! Win32 est _irrecuperable_. Mais
certaines API contiennent de bonnes idees (oui c'est rare) a
reutiliser dans des bibliotheques libres. Et a mon avis le noyau NT
est ameliorable (ca permettrait d'avoir du NT qui plante pas, deja, et
pour qui doit aussi bosser avec [pour d'inevitables mauvaises raisons]
c'est beaucoup).

> Mais en quoi les logiciels commerciaux ne serait-ils pas libres ?
> (je n'ai pas dit sous GPL) Ils bénéficieraient de tout autant de
> marketing, si ce n'est plus en ce moment, vu l'effet de mode actuel.

Parce qu'un logiciel libre peut difficilement s'elaborer dans le
secret. Or dans un secteur hautement concurrentiel le secret fait
partie des armes indispensables pour profiter du benefice de
l'innovation face a la concurrence.

La ou ca devient absurde, c'est quand des concepteurs d'OS en arrivent
a brider ou a refuser de documenter des APIs pour maintenir une
politique de prix biaisee.

Faire du LL commercial c'est vachement plus dur. Deja il faut viser le
long terme, chose qui effraie pas mal de boites quand on parle
d'informatique. En suite il faut etre au top techniquement. Enfin il
faut avoir les commerciaux et le service qui suivent derriere. Mais
visiblement ca paie, et plutot bien en plus.

> Mais je ne vois pas ce qu'une telle "formation" (le mot est trop formel
> à mon goût) a de pire que la formation qu'acquièrent chaque jour
> les développeurs sur des tas d'autres sujets (programmation C, Gtk,
> etc...).

Ben, un standard c'est plutot fait pour ne pas bouger tout le
temps. Quand on ne peut plus faire evolueur le standard, vaut mieux
essayer d'en creer un autre en parallele sans casser le premier.

> Une rupture, c'est douloureux, ça ne fait pas plaisir à grand monde,
> même quand c'est justifié. Si on doit attendre la prochaine rupture,
> ça risque de prendre pas mal de temps, en effet !

Il y a interet que ce soit vachement bien justifie alors. Sinon c'est
un code fork (comme il en existe plein, cf actuellement les demons
ftp).

[Herve Eychenne]

Julien Plissonneau Duquene <jpl...@abul.org> wrote:

>> Il est vrai qu'il y a quelques concepts intéressants. Mais Windows
>> NT est tellement monolithique (comparé à ce qu'il aurait pu être)
>> qu'il faut voir le tout dans son ensemble: et le tout est difficilement
>> récupérable.

> Mais je ne suis pas d'accord ! Win32 est _irrecuperable_. Mais

> certaines API contiennent de bonnes idees (oui c'est rare) a
> reutiliser dans des bibliotheques libres.

Alors il n'y a qu'à le faire. Tu t'y colles ?

> Et a mon avis le noyau NT est ameliorable (ca permettrait d'avoir du
> NT qui plante pas, deja, et pour qui doit aussi bosser avec [pour
> d'inevitables mauvaises raisons] c'est beaucoup).

Et si on changeait plutôt toutes les mauvaises raisons d'utiliser
NT en bonne raisons d'utiliser des OS libres, laissant NT de côté ?

>> Mais en quoi les logiciels commerciaux ne serait-ils pas libres ?
>> (je n'ai pas dit sous GPL) Ils bénéficieraient de tout autant de
>> marketing, si ce n'est plus en ce moment, vu l'effet de mode actuel.

> Parce qu'un logiciel libre peut difficilement s'elaborer dans le

> secret. Or dans un secteur hautement concurrentiel le secret fait
> partie des armes indispensables pour profiter du benefice de
> l'innovation face a la concurrence.

Bon, je suis d'accord pour les technologies hautement concurrentielles.
Mais pourquoi ne pas faire tomber les innovations dans le domaine
public au bout d'une certaine période (qui serait relativement courte,
vu le rythme d'évolution en informatique) ?

> [...]

> Faire du LL commercial c'est vachement plus dur. Deja il faut viser le
> long terme, chose qui effraie pas mal de boites quand on parle
> d'informatique.

En quoi faut-il absolument viser le long terme ?

> En suite il faut etre au top techniquement. Enfin il faut avoir les
> commerciaux et le service qui suivent derriere. Mais visiblement ca
> paie, et plutot bien en plus.

Alors cela devrait logiquement se généraliser, puisque tout le monde
peut y trouver son compte !...

>> Mais je ne vois pas ce qu'une telle "formation" (le mot est trop formel
>> à mon goût) a de pire que la formation qu'acquièrent chaque jour
>> les développeurs sur des tas d'autres sujets (programmation C, Gtk,
>> etc...).

> Ben, un standard c'est plutot fait pour ne pas bouger tout le

> temps. Quand on ne peut plus faire evolueur le standard, vaut mieux
> essayer d'en creer un autre en parallele sans casser le premier.

Si le standard n'est pas évolutif, c'est qu'il a quelque part été mal
conçu. Cela dit, je suis plutôt d'accord, mais je ne vois pas où tu veux
en venir.

>> Une rupture, c'est douloureux, ça ne fait pas plaisir à grand monde,
>> même quand c'est justifié. Si on doit attendre la prochaine rupture,
>> ça risque de prendre pas mal de temps, en effet !

> Il y a interet que ce soit vachement bien justifie alors. Sinon c'est

> un code fork (comme il en existe plein, cf actuellement les demons
> ftp).

Justement, le but est d'éviter les forks inutiles, et de faire migrer
les applications existantes en douceur vers un standard négocié (et
évolutif).

[Herve Eychenne]

Pablo Saratxaga <sr...@chanae.alphanet.ch> wrote:

> Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> said:

> HE> Cela ne veut pas dire qu'un temps non négligeable n'est
> HE> pas gaspillé

> C'est sur ce mot "gaspillage" que se porte le débat en fait.
> Deux équipes qui developperaient deux projets semblables suivant un modèle
> fermé feraient effectivemment du gaspillage; mais lorsqu'on suit
> un modèle de developpement ouvert et à fortiri s'il est libre; ce n'est
> plus vraiment du gaspillage; puisque les idées et le code peuvent être
> réutilisées (et elles le sont! Gnome à pioché pas mal dans KDE et sans doute
> l'inverse est-il vrai aussi;

Vu la similarité de fonction (et même de look) de certaines parties,
assurément.

> il existe en tout cas des ML avec justemment comme but le dialogue
> entre developpeurs des deux projets pour l'échange d'idées).

Ah, je ne savais pas.
Ce que cela m'inspire d'emblée, c'est qu'il est dommage que les deux
projets soit suffisamment raisonnables pour se consulter ouvertement,
mais pas assez pour fédérer, au lieu de se copier l'un l'autre.

> Autre chose très importante: les logiciels libres sont developpés souvent
> pour satisfaire les besoins de ceux qui les developpent; il ne s'agit donc
> pas de gaspillage, dans le chef des interessés.

Oui. Mais je raisonnais plus en terme d'utilisation finale, qui pâtit
de plusieurs développements parallèles quasi-équivalents.

> HE> Il ne s'agit pas de remettre en cause la liberté de chacun, mais de
> HE> fournir un cadre de travail qui bénéficierait à tout le monde, même si
> HE> personne n'était obligé de le suivre (que d'évidences...).

> Le problème est qu'un cadre trop rigide ne sera pas suivi.
> Par exemple le cadre GNU pour les traductions, je le trouve trop rigide
> et chiant (lettre papier à envoyer en recommandé par exemple),

Vraiment ? Par lettre papier ? Alors ça, ça me la coupe. Mais je ne connais
pas les modalités de la chose. Je ne peux pas imaginer qu'il n'y ait pas
une raison...

> Il m'a été reproché il y a quelque temps, d'aider et d'essayer de pousser
> les traductions en langues euskara et catalane; sous le pretexte que,
> sur les territoires où sont employés ces langues, tout le monde connaît
> soit l'espagnol soit le français; et que donc des projets de traduction en
> catalan ou en euskara sont une perte de temps et de moyens.

Je ne pense pas que ce soit une perte de temps, à partir du moment où
ces traductions sont faites par des gens qui ne sont pas des développeurs,
mais qui ont bien sûr le minimum de compétences requises pour faire
ces traductions, informatiquement parlant (pas linguistiquement, c'est
implicite).
Ca me fait toujours mal au coeur de voir un développeur "perdre son temps"
à traduire un truc alors que quelqu'un d'autre pourrait le faire,
alors même qu'il pourrait apporter une bien plus grande valeur ajoutée
(disons, que n'importe qui ne serait pas capable d'apporter).
A chacun ses compétences. Celles-ci doivent être le mieux réparties
possibles pour le bien de la communauté.

> Je ne suis pas d'accord, je trouve qu'il y a un besoin pour certaines
> personnes d'utiliser les programmes dans leur langue; même s'ils en
> comprennent une ou plusieures autre.
> Et tout besoin doit être satisfait.

Soit.

> Le problème du gaspillage n'en est un que si on regarde le logiciel
> libre avec un esprit mercantiliste, de recherche de rentabilité;

Si on doit employer ce mot pour le logiciel libre, c'est bien sûr dans
le sens d'un maximum de possibilités différentes et de puissance offerte
aux utilisateurs.

> mais c'est àmha une mauvaise approche; le but principal du logiciel
> libre est de satisfaire des besoins, peu importe le coût necessaire
> pour cela (bien sûr les besoins qui peuvent être satisfaits avec un
> faible coût le seront plus facilement et rapidemment; mais les
> autres le seront aussi; le doivent aussi)

C'est une définition philosophique. Une bonne.
Mais comme je le disais, il reste en pratique infiniment trop de
choses à faire pour que cela soit un dogme applicable à court terme.

> HE> Et alors, il y a suffisamment de choses non encore effectuées pour que le
> HE> talent des programmeurs qui bossent simultanément sur des projets quasi-
> HE> identiques soit mieux réparti.

> Pas necessairemment. Si on n'avait qu'un seul projet au lieu des deux
> KDE et Gnome; il y a fort à parier que le nombre de core developpers
> ne serait pas égal à la somme des core developpers des deux projets;

<MODE candide>
A cause des limites structurelles de gestion d'un seul et même projet ?
</MODE candide>

C'est possible. Peut-être la concurrence a-t-elle induit une réaction
de part et d'autre.

> il y aurait donc un certain nombre de developpeurs qui n'en feraient pas
> partie, qui n'auraient donc pas la possibilité d'accroitre leur experience
> personnelle (et donc l'experience globale).

Toute expérience est bonne à prendre, mais le raisonnement a ses limites.

> Si le projet Gnome n'avait pas vu le jour la bibliothèque Gtk+ ne serait pas
> ce qu'elle est aujourd'hui;

Euh... tu voulais dire Gimp, je suppose ?

> et le projet Harmony en tant que creation d'un clone compatible au
> niveau API n'aurait pas, et de loin, permis d'innover.

Innover en quoi ??

>> HE> Il est donc capital de fournir des modèles réutilisables, à tous les
>> HE> niveaux possibles.

> Mais il est tout aussi capital de fournir des possibilités d'entrâinement,
> d'acquisition d'experience et de savoir faire.

Les deux sont étroitement liés. A la limite, je te concède que si tout est
fait trop parfaitement, bien moins de gens auront envie (besoin) d'aller
tripatouiller dans le code.
Ce raisonnement s'applique à tous les niveaux.
Quand un système marche trop bien, nul besoin d'aller voir ce qui ne va
pas; alors que les problèmes rencontrés constituent une source
d'informations et d'auto-formation irremplaçable.
J'en sais quelque chose, j'ai passé un mois à temps plein plongé dans
les docs pour installer Linux il y a 4 ans. Quel aurait été mon niveau
dans 4 ans, si j'avais débuté aujourd'hui avec une Redhat 6.0 qui
s'installe les doigts dans le nez ? Bien moindre, certainement.

> HE> Tant mieux ! Cite-moi un logiciel libre qui soit conforme à tous les
> HE> critères que j'énonçais plus haut.
> HE> Je ne demande qu'à te croire.

> Ce n'est pas encore totalement operationnel; mais c'est le but qui
> sous-tend l'utilisation de CORBA dans Gnome: avoir des éléments reutilisables
> et pouvant s'emboîter les uns les autres; en bref l'équivalent graphique du
> pipe de la ligne de commande.
> Il y a quelques exemples de petits programmes en scheme ou python.

> Il est à noter qu'un tel projet ne peut être réellement testé qu'avec
> l'existance d'un certain nombre d'applications et d'éléments independants
> correspondant à certaines normes; il me semble que Gnome et KDE sont les
> premiers projets libres permettant cela; c'est donc realtivemment neuf.

A noter que ce n'est certainement pas un hasard si cela voit le jour
avec des projets aussi gros, dont la gestion ne peut qu'exiger un découpage
modulaire irréprochable.

> Mais un certain nombre de personnes ont conscience du besoin que tu exprimes
> de modularité et de reutilisation.

Pas encore assez à mon goût. ;-)
Mais ça vient, je suis d'accord.

> HE> Pour dégager une interface (non visuelle) commune à Windowmaker,
> HE> AfterStep, Fvwm et les autres, tu crois que l'idée peut germer des
> HE> développeurs des ces derniers ? Ca m'étonnerait franchement.
> HE> Ils sont chacun bien trop centrés (et c'est tout à fait logique) sur
> HE> leurs applications respectives.
> HE> Quelqu'un d'extérieur à ces équipes peut proposer un changement par le
> HE> haut (puisqu'un changement pas le bas est exclu vu le degré d'avancement).
> HE> Il prend contact avec chacune des équipes, discute du bien-fondé de la
> HE> chose, et négocie.
> HE> Si le projet semble bon, il sera vraisemblablement adopté, tu le dis
> HE> toi-même. Sinon, tant pis.

> Tout à fait; je suis à 100% d'accord.
> j'avais seulement, lors de la première lecture, pas vu le "negotiation".

> Sinon, ce qui est encore mieux: modifier un WM, tester, et envoyer le diff
> à ceux qui le mantiennent.

Oui: identifier les fonctionnalités communes (et centralisables),
implémenter une librairie, et modifier un gestionnaire de fenêtre
pour qu'il l'utilise. Mais c'est un boulot énorme, qui ne peut être
assuré par une seule personne, et recquiert sans doute l'intelligence
de toute les équipes bossant sur des gestionnaires de fenêtre.

Et encore, on ne parle là que de cette catégorie d'applications...

[Pablo Saratxaga]

Kaixo!
on 28 Apr 1999 01:03:11 GMT,
Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> said:

HE> On dérive, là ! Il ne s'agirait nullement de copier le modèle
HE> cathédrale, mais d'organiser de petites cathédrales pleines de bazar
HE> aux bons endroits.
HE> C'est déjà le cas pour le noyau, la libc, et X. De belles réussites.
HE> Il faudrait peut-être s'en inspirer (à plus petite échelle) dans des
HE> parties de code de plus haut niveau.

Tu oublies de preciser l'existance d'autres noyaux (les *BSD, Hurd, ELKS,...),
d'autres libc (car la GNU libc 2 ne s'est imposé qu'il y a quelques mois
à peine; jusque là on avait bien plusieurs projets parallèles), pour X
c'est vrai que à part XFree86 je ne vois pas d'autres projets libres;
mais à noter aussi que XFree86 n'est pas l'originateur de X11 mais qu'il
s'agit d'une reimplementation; ce serait plus à rapprocher de Wine ou de
lesstif. Il est clair que les possibilités de code fork sont bien moins
grandes dans ces cas là.

Finalement je trouve qu'il y a moins de gaspillage dans la dichotomie
Gnome/KDE, qu'il n'y a dans la foultitude de programmes, uniques dans leur
créneau, qui doivent tous à chaque fois réecrire le code pour leur barre
de menus, leur gestion de leurs fichiers de config, etc.

[Pablo Saratxaga]

Kaixo!
on 27 Apr 1999 12:49:14 GMT,
Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> said:

>> Lis la signature du type qui a pondu l'article, il travaille pour Microsoft,
>> et pour le project "Money" qui plus est.
>> C'est à dire que non seulement il est fort probable que ce qu'il dit
>> soit partisan, voire du FUD comandé par son employeur;

HE> Intéressante précision, même s'il on en n'avait nul besoin pour réfuter
HE> l'article en bloc.

En effet; mais ce qui m'a deplu c'est que l'auteur se decrive comme
"supporteur du logiciel libre" et signe contrat avec Microsoft, qu'il
critique ceux qui "reinventent la roue", et qu'il entre dans un projet
chez Microsoft (Money) qui fait exactemment ça !
Je n'aime pas l'hypocrisie.

HE> Bien sûr que le développement est ultra-rapide ! Mais à mon avis, c'est
HE> en partie dû au grand accroissement des effectifs

Et des moyens de communication; tout à fait.

HE> Cela ne veut pas dire qu'un temps non négligeable n'est
HE> pas gaspillé

C'est sur ce mot "gaspillage" que se porte le débat en fait.

DEux équipes qui devellopperaient deux projets semblables suivant un modèle

fermé feraient effectivemment du gaspillage; mais lorsqu'on suit
un modèle de developpement ouvert et à fortiri s'il est libre; ce n'est
plus vraiment du gaspillage; puisque les idées et le code peuvent être

reutilisées (et elles le sont! Gnome à pioché pas mal dans KDE et sans doute
l'inverse est-il vrai aussi; il existe en tout cas des ML avec justemment comme

but le dialogue entre developpeurs des deux projets pour l'échange d'idées).

Autre chose très importante: les logiciels libres sont developpés souvent

pour satisfaire les besoins de ceux qui les developpent; il ne s'agit donc
pas de gaspillage, dans le chef des interessés.

HE> Il ne s'agit pas de remettre en cause la liberté de chacun, mais de

HE> fournir un cadre de travail qui bénéficierait à tout le monde, même si
HE> personne n'était obligé de le suivre (que d'évidences...).

Le problème est qu'un cadre trop rigide ne sera pas suivi.
Par exemple le cadre GNU pour les traductions, je le trouve trop rigide

et chiant (lettre papier à envoyer en recommandé par exemple), je ne l'utilise
pas et ne compte pas l'utiliser; ce qui n'empêche pas que les traductions
ont bien lieu.

HE> !! Ah... Faire la même chose deux fois, l'une avec Qt, l'autre avec
HE> Gtk, ce n'est pas du temps perdu ?

Pas du point de vue de ceux qui le font; s'ils le font c'est parcequ'ils
en éprouvent le besoin.

Il m'a été reproché il y a quelque temps, d'aider et d'essayer de pousser
les traductions en langues euskara et catalane; sous le pretexte que,
sur les territoires où sont employés ces langues, tout le monde connaît
soit l'espagnol soit le français; et que donc des projets de traduction en
catalan ou en euskara sont une perte de temps et de moyens.

Je ne suis pas d'accord, je trouve qu'il y a un besoin pour certaines

personnes d'utiliser les programmes dans leur langue; même s'ils en
comprennent une ou plusieures autre.
Et tout besoin doit être satisfait.

Le problème du gaspillage n'en est un que si on regarde le logiciel libre

avec un esprit mercantiliste, de recherche de rentabilité; mais c'est

àmha une mauvaise approche; le but principal du logiciel libre est de
satisfaire des besoins, peu importe le coût necessaire pour cela (bien sûr
les besoins qui peuvent être satisfaits avec un faible coût le seront plus
facilement et rapidemment; mais les autres le seront aussi; le doivent aussi)

HE> Et alors, il y a suffisamment de choses non encore effectuées pour que le

HE> talent des programmeurs qui bossent simultanément sur des projets quasi-
HE> identiques soit mieux réparti.

Pas necessairemment. Si on n'avait qu'un seul projet au lieu des deux
KDE et Gnome; il y a fort à parier que le nombre de core developpers
ne serait pas égal à la somme des core developpers des deux projets;

il y aurait donc un certain nombre de developpeurs qui n'en feraient pas
partie, qui n'auraient donc pas la possibilité d'accroitre leur experience
personnelle (et donc l'experience globale).

D'ailleurs de nombreux projets libres ont vu le jour uniquemment comme
projet personnel d'une personne, pour qu'elle puisse acquerir une certaine
experience dans un domaine donné; Linux en est l'exemple le plus connu
sans doute.
Rien que pour ça ça vaut largemment la peine, car le "gaspillage" en temps
et en moyens, est aussi un enrechissement en experience et en savoir faire,
individuel et collectif.

Si le projet Gnome n'avait pas vu le jour la bibliothèque Gtk+ ne serait pas

ce qu'elle est aujourd'hui; et le projet Harmony en tant que creation d'un

clone compatible au niveau API n'aurait pas, et de loin, permis d'innover.

> HE> Il est donc capital de fournir des modèles réutilisables, à tous les
> HE> niveaux possibles.

Mais il est tout aussi capital de fournir des possibilités d'entrâinement,

d'acquisition d'experience et de savoir faire.

HE> Tant mieux ! Cite-moi un logiciel libre qui soit conforme à tous les
HE> critères que j'énonçais plus haut.
HE> Je ne demande qu'à te croire.

Ce n'est pas encore totalement operationnel; mais c'est le but qui
sous-tend l'utilisation de CORBA dans Gnome: avoir des éléments reutilisables
et pouvant s'emboîter les uns les autres; en bref l'équivalent graphique du
pipe de la ligne de commande.
Il y a quelques exemples de petits programmes en scheme ou python.

Il est à noter qu'un tel projet ne peut être réellement testé qu'avec
l'existance d'un certain nombre d'applications et d'éléments independants
correspondant à certaines normes; il me semble que Gnome et KDE sont les
premiers projets libres permettant cela; c'est donc realtivemment neuf.

Mais un certain nombre de personnes ont conscience du besoin que tu exprimes
de modularité et de reutilisation.

Je ne connais pas bien KDE; mais dans Gnome, outre CORBA, il y a l'utilisation
d'un certain nombre de bibliothèques qui permettent très facilement de
realiser certaines opérations, de manière standardisée, coherante, et
avec un certain nivceau d'abstraction; c'est le cas pour la lecture/écriture
des fichiers de config, l'utilisation du son, l'interaction avec /proc (ou
son equivalent sous d'autres OS), la creation et manipulation d'elements
standards (barres de menus, boutons, fenêtres de dialogue standard).

gnome-chess, utilise GNU chess (qui est en mode texte) comme moteur; et
ne fait que lui ajouter une couche graphique par dessus.
C'est le cas d'un certain nombre d'autres applications, comme le chercheur
de fichiers (qui utilise find/locate).

HE> Pour dégager une interface (non visuelle) commune à Windowmaker,
HE> AfterStep, Fvwm et les autres, tu crois que l'idée peut germer des
HE> développeurs des ces derniers ? Ca m'étonnerait franchement.
HE> Ils sont chacun bien trop centrés (et c'est tout à fait logique) sur
HE> leurs applications respectives.
HE> Quelqu'un d'extérieur à ces équipes peut proposer un changement par le
HE> haut (puisqu'un changement pas le bas est exclu vu le degré d'avancement).
HE> Il prend contact avec chacune des équipes, discute du bien-fondé de la
HE> chose, et négocie.
HE> Si le projet semble bon, il sera vraisemblablement adopté, tu le dis
HE> toi-même. Sinon, tant pis.

Tout à fait; je suis à 100% d'accord.
j'avais seulement, lors de la première lecture, pas vu le "negotiation".

Sinon, ce qui est encore mieux: modifier un WM, tester, et envoyer le diff
à ceux qui le mantiennent.

--

[Herve Eychenne]

Pablo Saratxaga <sr...@chanae.alphanet.ch> wrote:

> Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> said:

> HE> On dérive, là ! Il ne s'agirait nullement de copier le modèle
> HE> cathédrale, mais d'organiser de petites cathédrales pleines de bazar
> HE> aux bons endroits.
> HE> C'est déjà le cas pour le noyau, la libc, et X. De belles réussites.
> HE> Il faudrait peut-être s'en inspirer (à plus petite échelle) dans des
> HE> parties de code de plus haut niveau.

> Tu oublies de preciser l'existance d'autres noyaux (les *BSD, Hurd,
> ELKS,...),

Qui sont tout autant centralisés, non ? (si ce n'est plus)

> d'autres libc (car la GNU libc 2 ne s'est imposé qu'il y

> a quelques mois à peine; jusque là on avait bien plusieurs projets
> parallèles), pour X c'est vrai que à part XFree86 je ne vois pas
> d'autres projets libres; mais à noter aussi que XFree86 n'est pas
> l'originateur de X11 mais qu'il s'agit d'une reimplementation; ce
> serait plus à rapprocher de Wine ou de lesstif. Il est clair que les
> possibilités de code fork sont bien moins grandes dans ces cas là.

C'est vrai.

> Finalement je trouve qu'il y a moins de gaspillage dans la dichotomie
> Gnome/KDE, qu'il n'y a dans la foultitude de programmes, uniques dans leur
> créneau, qui doivent tous à chaque fois réecrire le code pour leur barre
> de menus, leur gestion de leurs fichiers de config, etc.

En volume total, sûrement ! En pourcentage... ;-)

> --
> À bientôt,
> Pablo Saratxaga PGP Key available, key ID: 0x8F0E4975

> http://www.ping.be/~pin19314/

--

[Stephane TOUGARD]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> wrote:

>> Cela ne fait que plus de projets, plus de choix. Nous avons les moyens
>> de coder dans tous les sens, notre main d'oeuvre est infinie (ou
>> presque, en tout cas elle a des moyens que meme MS n'a pas).

> Oui, évidemment. Mais la question est: est-ce que ça vaut toujours le
> coup de coder dans tous les sens ?

Au moins pour apprendre, oui. J'ai ecrit des programmes qui n'ont jamais
servi a rien qu'a m'apprendre a les ecrire.

>> Meme argument, et alors ? L'existence de Gnome ne remet pas en cause
>> celle de Kde, celle de Sendmail contre Exim,... Plus de choix, du
>> gachis, on s'en fout.

> On peut prendre ce parti, évidemment. Mais ça me fait tout de même un
> peu mal au coeur... Enfin... :-(

Que vas tu faire des codeurs alors ? Tu as des projets, tu commences,
des gens te rejoindront. Face au potentiel, le gachis est en fait
minime.

>>> souvent un frein, devant l'accumulation de cas particuliers dans la
>>> forme, mais redondants sur le fond;

>> Cela ne me gene pas et je doute que cela gene bcp de monde.

> Moi non plus, d'un point de vue pratique. Mais d'un point de vue
> conceptuel, ce serait vraiment très intéressant.
> Eh puis, à mon avis, si ça ne manque pas à grand monde, c'est que
> personne n'y a encore goûté.

De quoi ? de mettre tous les programmeurs dans des directions precises,
de tuer l'initiative individuelle au profit d'une direction generale
mieux geree ? Ce n'est pas mon avis en tout cas, Linux est ne de
l'initiative individuelle et de la collectivisation de cette initiative,
c'est une premiere mondiale et tu dis qu'il y a du gachis ?

>> Plus il y aura de distributions, plus il y aura de supports pour porter
>> Linux,

> Trop de Linux différents finiraient par "tuer" Linux. Je n'ai pas dit
> le faire disparaître, mais l'empêcher de tenir un jour la place qu'il
> mérite.

J'attend un argument plus serieux qu'une simple affirmation.

>>> Des efforts de standardisation tels que le LSB sont à mon avis plus que
>>> jamais nécessaires.

>> Necessaires ? pratique, oui, mais necessaires,...

> Cf ci-dessus.
> Au delà de ça, on pourrait dire: "pratique, donc nécessaire". ;-)

Argumente, arguemente, ce n'est pas tres convaincant tout ca.

>> Mais qui ne coute rien,

> Ca n'est pas parce qu'une chose ne coûte rien que ça ne me gêne pas
> de la voir gaspillée.

Ne codez plus les gars, c'est du gachis, ne codez plus exim, Sendmail
existe, ne codez plus AfterStep, Gnome, FVWM,... Gnome existe. Et si moi
je veux utiliser AfterStep et si moi je veux utiliser Exim.

> Justement. Si Linux tourne sur tant d'architectures différentes, c'est
> parce que le noyau est bien agencé, puisqu'il isole les parties
> dépendantes de chaque architecture (/usr/src/linux/arch/*), et que la
> libc fournit une bonne couche d'abstraction.
> Ces deux couches sont parmi les plus centralisées qui soient au milieu
> du développement bazar de Linux, et ce n'est pas un hasard.

Il tourne sur tout, surtout parce qu'il est bien ecrit, cela est du,
c'est certain, au talent de ses auteurs et un peu moins a l'organisation
qui est derriere. Sendmail tourne tres bien sur ma Sparc mais Exim s'y
refuse, heureusement que j'ai un choix.

--
Attention, mon adresse E-Mail a change. <el...@easynet.fr>

[Arnaud Gomes-do-Vale]

Salut,

Juste un point sur lequel je voudrais revenir:

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:

> Oui. Il n'empêche que s'ils [MS] voulaient tout refaire, leur puissance

> est devenue telle que beaucoup de gens les suivraient (ou ne pourraient
> faire vraiment autrement que de les suivre). Plus pour longtemps,
> espérons.

Je ne comprends pas cette affirmation. Dans la mesure ou le gros
argument de MS est a compatibilité avec l'existant, je ne vois pas
pourquoi "beaucoup de gens" referaient la même erreur que par le passé
alors qu'il faudrait changer de toute façon.

--
Arnaud Gomes-do-Vale ---- gom...@mail.dotcom.fr
http://www.chez.com/gomesdv/
Folium: http://www.ecoledoc.lip6.fr/~capricel/folium/
"Si ça continue, faudra que ça cesse" (H.F. Thiéfaine)

[Herve Eychenne]

Arnaud Gomes-do-Vale <arn...@pumpkin.pumpkin.home> wrote:

> Juste un point sur lequel je voudrais revenir:

>> Oui. Il n'empêche que s'ils [MS] voulaient tout refaire, leur puissance

>> est devenue telle que beaucoup de gens les suivraient (ou ne pourraient
>> faire vraiment autrement que de les suivre). Plus pour longtemps,
>> espérons.

> Je ne comprends pas cette affirmation. Dans la mesure ou le gros

> argument de MS est a compatibilité avec l'existant, je ne vois pas
> pourquoi "beaucoup de gens" referaient la même erreur que par le passé
> alors qu'il faudrait changer de toute façon.

On n'imagine jamais assez la force du lien qui tient les utilisateurs
de Windows à Microsoft, rien qu'à travers les fichiers d'Office.
Ensuite, il est devenu tellement banal de travailler sous Windows
que les gens croient bien le connaître, et ne seraient près pour rien
au monde à changer.
Ne jamais sous-estimer l'inertie de l'utilisateur de base (et ils
sont plus que nombreux).

[costaclt]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> a écrit dans l'article

> On n'imagine jamais assez la force du lien qui tient les utilisateurs
> de Windows à Microsoft, rien qu'à travers les fichiers d'Office.
> Ensuite, il est devenu tellement banal de travailler sous Windows
> que les gens croient bien le connaître, et ne seraient près pour rien
> au monde à changer.
> Ne jamais sous-estimer l'inertie de l'utilisateur de base (et ils
> sont plus que nombreux).

J'en arrive à croire que les difficultés liées à l'implantation de Linux
sont d'abord du domaine de la gestion des ressources humaines avant d'être
du ressort de la technique.

Il me semble qu'il y a beaucoup de questions à se poser sur l'origine de
certains comportements, surtout du fait que ces comportements paraissent
stéréotypés et transversaux.

- Pourquoi les utilisateurs ne lisent-ils pas la documentation ?

Dans les entreprises, personne ne lit et ne lira jamais une documentation
papier. Qu'il s'agisse du cadre ou de l'ouvrier, le comportement est
identique. De rares individus lisent la doc sous forme d'aide intégrée au
logiciel, mais ils la lisent toujours de manière parcellaire. Pourquoi ? En
général, les utilisateurs font référence au temps et à l'urgence. Mais
lorsqu'ils sont en formation, c'est la même chose. Du reste, beaucoup
d'étudiants ne lisent pas non plus les docs. De quoi ont-ils peur ? On a
l'impression qu'ils veulent se réserver un espace de "surprises" (ah tiens,
ce soft est capable de faire ça !).

- Pourquoi les utilisateurs n'utilisent-ils pas leurs softs à plein régime
?

Ils utilisent leur voiture "à fond la caisse" mais sous-utilisent leurs
softs, même s'ils sont toute la journée penchés sur leur ordinateur. Je
vois des cadres utiliser depuis des années Word ou Excel et découvrir un
beau jour que leur traitement de texte peut faire aussi des calculs simples
et leur tableur simuler des scénarios. Leur réponse est souvent :" On
n'utilise que ce dont on a besoin". En fait, on leur montre une nouvelle
fonctionnalité et ils se découvrent très vite un besoin...

- Pourquoi l'utilisateur souhaite-t-il changer constamment de version de
soft ?

Il y a de l'inertie. Mais cette inertie ne touche pas le changement des
versions de produits. Elle ne touche pas non plus l'acquisition
d'utilitaires. Lorsqu'on regarde la base de registre de Windows sur le pc
d'un cadre ou d'un étudiant, on s'aperçoit qu'il a déjà installé je ne sais
combien de versions différentes d'un soft et qu'il ne renonce jamais à
l'utilitaire livré gracieusement par son magasine favori. En fait, il se
crée des emmerdements en boucle : il maîtrise à peine un soft qu'il en
change pour faire connaissance avec une version qu'il connaîtra encore
moins et qui va générer des erreurs. Pourquoi ?

- Pourquoi l'utilisateur se passionne-t-il pour des softs qui ne concernent
pas son boulot ou ses besoins immédiats ?

Le cadre et l'étudiant adorent les images et les sons. Au niveau
papier-peint et écran de veille, ils sont très performants. Surtout si
c'est un peu erotico-porno. Les scanners et Photoshop passionnent : les
utilisateurs ont-ils une vocation artistique flouée ? La répression
est-elle si forte que l'érotisation ne peut pas s'effectuer sur les
relations concrètes des groupes à l'intérieur d'une organisation ?

- Pourquoi l'utilisateur adopte-il si tranquillement une position cynique ?

Il devient rare de trouver des utilisateurs ne maudissant pas MS. Cela ne
change rien à leurs choix. Cela me fait toujours penser à cette attitude
dite du "rire du pendu" : on prend plaisir à ses propres conneries "ah
qu'est-ce que je me suis fait avoir par Billou !".

- Pourquoi les utilisateurs en situation professionnelle utilisent-ils des
méthodes caduques ?

Les étudiants sont en général très surpris : ils apprennent des choses
sophistiquées et atterrissent dans des entreprises qui travaillent avec des
méthodes éculées ( qu'on désigne pudiquement sous le nom "d'expérience du
terrain"). Ceci est valable dans tous les secteurs. En ce sens, les softs
de MS sont infiniment sophistiqués par rapport aux pratiques concrètes.
Essayez de montrer à quoi sert MS Project : vous verrez que la
planifiacation, l'idée de ressource et d'affectation sont de grandes
inconnues dans les pratiques réelles. Pourquoi cet amateurisme ?

- Pourquoi les utilisateurs souhaitent-ils ignorer les enjeux de tout ce
qui ne concerne pas directement leur centre d'intéret immédiat ?

Les linuxiens sont souvent, d'après les posts en tout cas, très soucieux
des enjeux techniques et non-techniques (disons sociaux pour aller vite) de
leur os favori. Il n'y a qu'à voir le côté pointilleux de la "querelle"
GNUEmacs et XEmacs. Mais dès que l'on sort de cet aspect restreint, tout
semble autorisé ou pardonné ou plus généralement ignoré. Et il s'agit d'une
constante dans les métiers. Ces oeillères, elles servent à quoi ?

Thierry

[Philippe Hermoso]

Herve Eychenne wrote:

>
> On n'imagine jamais assez la force du lien qui tient les utilisateurs
> de Windows à Microsoft, rien qu'à travers les fichiers d'Office.
> Ensuite, il est devenu tellement banal de travailler sous Windows
> que les gens croient bien le connaître, et ne seraient près pour rien
> au monde à changer.
> Ne jamais sous-estimer l'inertie de l'utilisateur de base (et ils
> sont plus que nombreux).
>

Oui, et combien d'entre eux pensent qu'un PC ne peut pas fonctionner
sans MS-Win ??
Combien d'utilisateurs de base n'ont jamais entendu le mots "Unix" ?
Combien d'entre, une fois que l'on leur a supprimé un raccourci ne
savent plus retrouver l'application ?

brrr... ça fait peur !

--
Philippe

[Herve Eychenne]

costaclt <cost...@easynet.fr> wrote:

>> On n'imagine jamais assez la force du lien qui tient les utilisateurs
>> de Windows à Microsoft, rien qu'à travers les fichiers d'Office.
>> Ensuite, il est devenu tellement banal de travailler sous Windows
>> que les gens croient bien le connaître, et ne seraient près pour rien
>> au monde à changer.
>> Ne jamais sous-estimer l'inertie de l'utilisateur de base (et ils
>> sont plus que nombreux).

> J'en arrive à croire que les difficultés liées à l'implantation de Linux
> sont d'abord du domaine de la gestion des ressources humaines avant d'être
> du ressort de la technique.

Les problèmes techniques peuvent être surmontés. A la limite, ce n'est
qu'une question de temps.
Mais les aspects humains du travail en groupe, et ce, tout
particulièrement s'ils ne disposent pour développer que des outils
actuels mis à leur disposition par Internet, seront toujours valables.

> Il me semble qu'il y a beaucoup de questions à se poser sur l'origine de
> certains comportements, surtout du fait que ces comportements paraissent
> stéréotypés et transversaux.

> - Pourquoi les utilisateurs ne lisent-ils pas la documentation ?

Pour la même raison qu'une majorité de français s'installe devant la
télé pour regarder Lagaff en rentrant du boulot: la paresse
intellectuelle.
Dans le même ordre d'idée, il faudra sans doute attendre de voir
transposer les grandes oeuvres en BD pour que les Français se mettent
à la littérature. ;-)

Note: ce point n'est pas près de s'arranger. La culture actuelle est celle
de l'instantané, de la consommation immédiate sans grand investissement
personnel.
Au rythme actuel, le type qui lira les documentations dans 20 ans aura
l'air d'un extra-terrestre.

> - Pourquoi les utilisateurs n'utilisent-ils pas leurs softs à plein régime
> ?

Ils n'utilisent que ce dont ils ont besoin immédiatement.
C'est de la paresse également. Connaître à fond leur logiciel impliquerait
de lire la documentation entièrement.

> En fait, on leur montre une nouvelle fonctionnalité et ils se
> découvrent très vite un besoin...

Très juste. Mais ils ne peuvent pas le savoir avant d'avoir lu la doc,
ou de se faire montrer une fonctionnalité par un autre utilisateur.
Quand je reçois un nouveau produit (qu'il soit logiciel ou non), ma 1ère
réaction est de jouer un peu avec, si je vois que je peux tâtonner sans
tout "casser".
Puis, passé cette période ludique (ou j'ai assimilé une bonne
partie des fonctions qui me serviront en utilisation courante), je me
plonge dans la doc.
Mais attention, pas dans le but de résoudre un problème précis ! Uniquement
pour avoir une idée de toutes les fonctionnalités disponibles.
L'important n'est ici pas forcément de savoir immédiatement résoudre un
problème, mais de savoir où (et surtout quoi !!) chercher si j'en ai
besoin ultérieurement.

> - POURQUOI l'utilisateur souhaite-t-il changer constamment de version de
> soft ?

Il s'agit de l'attrait de la nouveauté. Mais attention, pas de n'importe
quelle nouveauté ! Mais d'un produit que l'utilisateur connaît déjà,
ou plutôt croît connaître. Ainsi, il dispose d'un point de comparaison.
Il pense que cela va lui permettre d'évoluer sans acquérir un nouveau
savoir (la paresse toujours).
Mais il y a tout de même un point à ne pas négliger: tout changement
est motivé par un besoin. Dans le cas de Microsoft, le besoin d'avoir un
logiciel qui marche.
Quand un logiciel est conforme au désir de l'utilisateur, celui-ci n'éprouve
pas le besoin de changer. Ainsi, j'utilise toujours une vieille Slackware 3.1
depuis belle lurette. Inutile de vous dire que j'en suis parfaitement
satisfait, que je ne changerai que lorsque j'éprouverai un manque par
rapport à une autre version ou distribution.

> - Pourquoi l'utilisateur se passionne-t-il pour des softs qui ne concernent
> pas son boulot ou ses besoins immédiats ?

Parce que, de la même manière que l'homme est quelque part fasciné par ce
qui lui est interdit, tout ce qui est imposé lui est généralement
désagréable. Il trouve là un moyen de "s'évader" du cadre imposé.

> Le cadre et l'étudiant adorent les images et les sons.

L'attrait du "multimédia". Ce qui bouge et fait du bruit passionne bien
plus l'utilisateur qu'une doc texte.

> - Pourquoi l'utilisateur adopte-il si tranquillement une position cynique ?

> Il devient rare de trouver des utilisateurs ne maudissant pas MS. Cela ne
> change rien à leurs choix. Cela me fait toujours penser à cette attitude
> dite du "rire du pendu" : on prend plaisir à ses propres conneries "ah
> qu'est-ce que je me suis fait avoir par Billou !".

> - Pourquoi les utilisateurs en situation professionnelle utilisent-ils des
> méthodes caduques ?

> Les étudiants sont en général très surpris : ils apprennent des choses
> sophistiquées et atterrissent dans des entreprises qui travaillent avec des
> méthodes éculées ( qu'on désigne pudiquement sous le nom "d'expérience du
> terrain"). Ceci est valable dans tous les secteurs. En ce sens, les softs
> de MS sont infiniment sophistiqués par rapport aux pratiques concrètes.
> Essayez de montrer à quoi sert MS Project : vous verrez que la
> planifiacation, l'idée de ressource et d'affectation sont de grandes
> inconnues dans les pratiques réelles. Pourquoi cet amateurisme ?

Par conservatisme, et parfois par sagesse.
Les gens font ce qu'ils savent faire, et s'y accrochent, même s'il existe
mieux ailleurs.

> - Pourquoi les utilisateurs souhaitent-ils ignorer les enjeux de tout ce
> qui ne concerne pas directement leur centre d'intéret immédiat ?

> Les linuxiens sont souvent, d'après les posts en tout cas, très soucieux
> des enjeux techniques et non-techniques (disons sociaux pour aller vite) de
> leur os favori. Il n'y a qu'à voir le côté pointilleux de la "querelle"
> GNUEmacs et XEmacs. Mais dès que l'on sort de cet aspect restreint, tout
> semble autorisé ou pardonné ou plus généralement ignoré. Et il s'agit d'une
> constante dans les métiers. Ces oeillères, elles servent à quoi ?

C'est de l'égoïsme, de l'indifférence, et un grand manque de recul.

L'utilisateur lambda se sert de ce que l'on lui vend, sans trop se
poser de questions. Il veut quelque chose qui marche à peu près, et
n'est pas bien exigeant. Quand il pense avoir trouvé ce qu'il lui
faut, peu lui importe de savoir que le voisin a trouvé mieux que lui
et qu'il s'est un peu fait avoir. Au contraire, il préférera ignorer
le voisin et essayera de s'auto-persuader qu'il a pris la bonne
décision pour ne pas trop "souffrir", allant jusqu'à se mentir à lui-même.

De plus, l'être humain raisonne souvent par rapport à lui. Mais surtout,
il agit comme si les conséquences de ses actes ne concernait que lui.
Même si on lui a expliqué qu'il n'agissait pas dans le bon sens, il
comptera sur les autres pour agir mieux que lui. Et ce, même s'il a
compris (par ce qu'on lui en a fait prendre conscience) que si tout le
monde agissait comme lui, le monde serait dans un bel état.

Exemple: une copine à qui j'ai passé une heure à faire prendre conscience
du désastre que représente les Winmodems (et autre Win-matériel potentiel)
pour l'informatique. Au bout de cette heure d'explication, elle avait
parfaitement pris conscience du fait que si tout le monde en achetait,
tout le monde serait pieds et poings liés à Microsoft, et que "ce ne serait
assurément pas une bonne chose pour l'humanité". Mais elle décidait tout
de même d'en acheter un "parce qu'elle n'utilise que Windows et qu'un
Winmodem est moins cher", en espérant "que tout le monde ne ferait pas
comme elle".

Moi je dis que dans ces cas-là, il n'y a plus grand chose à faire.
Je suis désolé de finir sur une note si pessimiste. ;-)

Bref, je crois que ton post recense une bonne partie des défauts humains,
appliqués à l'informatique. ;-)

La bonne nouvelle, c'est qu'il reste (peut-être) encore suffisamment
de gens censés pour sauver les autres d'eux-mêmes.

[Nat Makarevitch]

Pablo Saratxaga writes:

> Par exemple le cadre GNU pour les traductions, je le trouve trop rigide
> et chiant

RMS n'essaie à ma connaissance pas d'entraver ces projets, au contraire !

mais il connaît bien la chanson et sait que des volontaires sont parfois
(souvent !) professionnels, et que leurs employeurs peuvent donc
revendiquer le fruit de leur travail devant une cour de justice.

une action illégale (par exemple 'libérer' une oeuvre sous copyright)
pourrait condamner le projet GNU. ces procédures lourdes (car
« classiques ») pourraient permettre de dégager sa responsabilité en cas
d'action en justice. GNU n'évolue pas hors du monde, donc ne se trouve pas
au-delà des lois.

--
<URL:http://www.linux-france.org/>
Passager d'avion ? DANGER ! <URL:http://www.sr111.org/>

[Nat Makarevitch]

(réponse à l'article 7g0no6$isv$1...@news.u-bordeaux.fr paru ds
fr.comp.os.linux.debats)

> "Un article du Chicago Tribune

> Linux n'est-il pas une perte de temps ?"

à mon sens cet échange relève plutôt de fr.comp.applications.libres, voire
de fcolm, n ?

> la question de la perte de temps dans le modèle de développement libre me
> semble bien réelle:

> - si la réutilisation de code était massive, une erreur détectée dans

> un code source pourrait très bien s'être largement propagée

o, mais sa diffusion même réduit la probabilité de survie du bug car de
nombreux utilisateurs et développeurs l'emploient de diverses manières. la
POO est adossée à cette conception (réutilisation, 'généricité' ...), et
elle donne satisfaction.

> - le développement du logiciel libre est assez anarchique.

rançon de la liberté dont le « coût » ne pèse pas sur l'ensemble du
mouvement mais sur ceux qui décident de développer ou d'utiliser, en
connaissance de cause.

> Trop de programmeurs semblent se lancer dans un projet sans prendre la
> peine de se renseigner pour savoir ce qui a été effectué auparavant sur
> le sujet;

cela concerne surtout certaines applications, car le reste adhère aux
normes. les développeurs doivent les étudier et examiner l'implémentation
de référence, et ils échangent des idées (Usenet, listes de diffusion,
conférences ...). cela les conduit naturellement à interagir avec leurs
pairs aux objectifs semblables, et donc à prendre connaissance de leurs
travaux.

> - le logiciel libre n'a pas empêché le développement de deux bureaux

> comparables tels que Gnome et KDE

la robustesse d'une espèce découle de sa diversité (lire
http://www.linux-france.org/article/these/libreevol/), et le nombre de
découvertes augmente avec celui des impétrants. ne pas négliger, par
ailleurs, que des projets bien distincts convergent souvent, à terme, y
compris après la mort de l'un d'eux. cela concerne aussi les logiciels
commerciaux (examiner l'arbre généalogique des Unix commerciaux).

> - le polymophisme des applications

> constitue trop souvent un frein, devant l'accumulation de cas

> particuliers dans la forme, mais redondants sur le fond;

> - chacun refait tout de même un peu les mêmes choses dans son coin.

mais qui jurerait qu'un nouveau projet restera en-déçà du précécent ? et
comment s'assurer qu'il ne bénéficiera pas aux autres ?
mieux vaut laisser tt cela s'auto-organiser. les codeurs pissent, leurs
pairs hument et sucrent, et les utilisateurs filtrent :-)

> les différentes distributions Linux améliorent leurs procédures
> d'installation en parallèle, sans que les uns bénéficient directement des
> avancées des autres

beaucoup examinent les développements des autres, et s'en inspirent.

> Si chacun s'était entendu sur un standard commun (de nivellement par le
> haut

si tu penses aux sous-jacents (arbo, fichiers de config ...) cela me semble
salutaire, et l'inertie projets concernés (LSB ...) m'attriste. ns
pourrions progresser en mobilisant les utilisateurs, en leur détaillant les
raisons pour lesquelles ns gagnerions ts à rejeter les logiciels ou
distributions qui ne les respectent pas.

mais ne tentont pas d'imposer des normes d'implémentation ou de
présentation, de factoriser tous les codes. invitons plutôt les
développeurs à implémenter en respectant les normes et sous forme de
bibliothèques. leurs pairs et les utilisateurs les emploieront ou n,
décidant ainsi de l'avenir des projets.

> que d'efforts auraient été épargnés...

le succès des logiciels libres doit beaucoup (sinon tout) à leur
qualité.

cette dernière procède de la revue des pairs (<= sources disponibles), des
emprunts (les développements des uns inspirent les autres), d'une saine
émulation (=> plusieurs projets 'concurrents'), et de la liberté offerte à
chacun de bricoler ce que bon lui semble (=> pas d'organisme adoubant les
projets). et aussi, parfois, de découvertes découlant de bricolages.

la redondance (du quantitatif, donc) est la rançon de ce gain qualitatif.
les résultats obtenus la rendent selon moi tolérable.

note : revue des pairs, efforts et projets multiples, découvertes devant
quasi tout au hasard ... tt cela s'apparente fortement à ce que connaît la
communauté des scientifiques. marrant.

même les auteurs de projets foireux (inutiles, mal conçus ...) y gagnent,
car il expérimentent, recueillent des commentaires (voire « recherchent les
causes de l'échec ») ... et apprennent.

> Des efforts de standardisation tels que le LSB sont à mon avis plus que
> jamais nécessaires.

o !

> l'ensemble de l'ouvrage finit tout de même par prendre forme, mais au

> prix d'un déploiement d'énergie trop souvent gaspillée.

connais-tu une autre approche préservant les avantages patents du 'bordel'
actuel ?

> Il est donc capital de fournir des modèles réutilisables, à tous les

> niveaux
[ ... ]
> fournir une bibliothèque de fonctions non interactives, au-dessus de
> laquelle seraient bâties les interfaces texte et graphique, avec un
> dialogue

réinventons la machine Lisp :-)

cela pose des problèmes (pas uniquement d'ordre tech) à ma connaissance non
résolus à ce jour, mais rien n'interdit de prospecter.

> l'absence d'un architecte garantissant une cohérence d'ensemble se

> fait parfois cruellement sentir.

respecter les normes de développement érigées par le projet GNU (tt
embarquer ds des bibliothèques, donc réduire l'adhérence, et fournir les
'liaisons' grâce auxquelles un langage offre à l'utilisateur le moyen de
conduire et d'étendre l'application) y suffisent, je crois.

mieux : on ne peut ménager de grande liberté lorsque même le mode
d'implémentation est bien spécifié. il reste toujours possible, en
revanche, d'assurer à un lot de logiciels libres une cohérence a
posteriori.
une entité quelconque (par exemple un éditeur, ou un projet de
développement d'Interface Homme/Machine) améliore d'ordinaire la cohérence
d'éléments disparates qu'elle sélectionne, réagence et prépare (par exemple
en une distribution, ou bien en modifiant des logiciels existants de sorte
qu'ils se fondent dans l'IHM).

> Le défi crucial est la modularité, ce qui suppose de s'entendre sur
> une interface respectée par chacun.

lire la section ''Pas « d'interface standard »'' de
http://www.linux-france.org/article/presentation/

mieux vaut convenir d'un langage d'extension commun, car cela réduit le
coût de conception (très élevé, si l'on souhaite réaliser des modules
directement interopérables) et étend davantage le registre fonctionnel
(scriptage).
écueil : nombre de béotiens n'apprendront probablement pas ce langage.
une soluce : clicodrome capable de rédiger des scripts (OK, très
ambitieux).

> L'initiative ne peut venir à mon sens que d'une volonté extérieure à

> chacune des équipes de développement

o !

mais des utilisateurs et n d'une organisation fédératrice. cette dernière
ne serait chargée que de publier des documents résultants de débats publics
qui détailleraint l'interêt et les modalités de cette approche.

> réinventer un peu moins la roue dans son coin, et de s'inscrire
> immédiatement dans un cadre cohérent.

lorsque l'on ne sait pas très bien où l'on va ni comment s'y rendre les
« co-errants » l'emportent sur les « cohérents » :-)

« cohérents » au pluriel, o ! car tu négliges peut-être l'importance d'un
écueil àmha efffrayant : la 'cohérence' de l'un n'est pas celle de
l'autre.
les débats (Usenet, listes ...) montrent que mêmes des experts ne partagent
pas un seul et même avis. obtenir un consensus s'avère alors coûteux, et y
renoncer condamne l'entreprise.

laissons les responsables de projets chercher, choisir, emprunter, rejeter
... et les utilisateurs trancher. un peu de confiance en l'homme :-)
(cet 'humanisme' correspond bien, je crois, à « l'esprit du libre »).

[costaclt]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> a écrit dans l'article

> Dans le même ordre d'idée, il faudra sans doute attendre de voir
> transposer les grandes oeuvres en BD pour que les Français se mettent
> à la littérature. ;-)

- Ce qui me rappelle un excellent dessin paru dans le Monde : une réunion
très mondaine dans laquelle une personne demande à l'autre "Vous avez lu la
Phénomènologie de l'Esprit ?". L'autre lui répond :"Ah non ! Moi j'attends
toujours que ça sorte en film avant de lire le livre".

> Quand je reçois un nouveau produit (qu'il soit logiciel ou non), ma 1ère
> réaction est de jouer un peu avec, si je vois que je peux tâtonner sans
> tout "casser".
> Puis, passé cette période ludique (ou j'ai assimilé une bonne
> partie des fonctions qui me serviront en utilisation courante), je me
> plonge dans la doc.

- Et c'est là que je constate chez la plupart des utilisateurs une
"rupture" : ils ne passent pas à la seconde étape. J'ai un doute sur l'idée
de paresse. Je me demande si cela n'a pas à voir avec la crainte. Voire la
peur qui semble être devenue un moteur social puissant (on a peur de perdre
son boulot, sa femme, sa base de registre, lilo, la face ...).

- En ce moment, la guerre est déclarée aux pollueurs de fcolc qui posent
des questions déjà traitées. Je crois que si ils les posent ces fichues
FAQ, ce n'est pas par méconnaissance de la netiquette ou des mans. C'est la
crainte qui dirige ces questions. L'administrateur NT a peur de basculer
sur Linux, le lycéen a peur de flinguer ses répertoires windows. C'est le
comportement classique de la petite vieille qui emmerde le contrôleur SNCF
alors que l'information lui est affichée sous le nez : il faut qu'une
personne identifiable la rassure.

- La crainte est déjà dans l'intitulé du post initial. Et si effectivement
Linux n'était qu'une perte de temps ? La crainte de dépenser des heures et
des espoirs au risque de voir le marché sanctionner ce type de softs. Le
parcours du linuxien est assez rude...

- La crainte générale de celui que l'informatique intéresse. Beaucoup de
gens se flattent de n'y rien connaître. Ils subodorent que l'intérêt pour
l'informatique, et pour linux qui est si peu rentable immédiatement, cache
quelque chose. On fait souvent référence à la concurrence qui existe entre
le bidouilleur informatique et ...la compagne. Curieux en effet qu'un
domaine professionnel récent, si peu investi par définition par des valeurs
masculines, n'interesse que très modéremment les femmes. La gente féminine
serait-elle bien plus avisée et n'aurait pas besoin de jouer avec un
ordinateur comme un adolescent joue avec un flipper : pas seulement pour
lancer la bille. Les coups de reins comptent aussi...

- La crainte qu'occasionne toute lecture. On se plaint des plantades de
windows. Vu comment il est utilisé dans les entreprises et chez les
particuliers, cad de manière "pépère", il ne devrait pas planter. Et pour
peu qu'on lise la doc, il ne plante pas. Seulement, une doc, cela commence
toujours bien. Puis viennent les exceptions aux règles. L'incertitude. On
croyait le bidule rationnel et bien non, il est aussi compliqué que la vie
courante. Et l'incertitude, vecteur de peur, a mauvaise presse aujourd'hui.
Alors on remet à plus tard le véritable affrontement.

> De plus, l'être humain raisonne souvent par rapport à lui. Mais surtout,
> il agit comme si les conséquences de ses actes ne concernait que lui.
> Même si on lui a expliqué qu'il n'agissait pas dans le bon sens, il
> comptera sur les autres pour agir mieux que lui. Et ce, même s'il a
> compris (par ce qu'on lui en a fait prendre conscience) que si tout le
> monde agissait comme lui, le monde serait dans un bel état.

- Ce qui est un impératif catégorique de la morale. Enfin pour Kant. Cela
ne nous rajeunit pas et même nous fait passer pour des petits vieux : se
faire avoir de la sorte, deux cents ans plus tard et sur une histoire de
winmodem !

>
> La bonne nouvelle, c'est qu'il reste (peut-être) encore suffisamment
> de gens censés pour sauver les autres d'eux-mêmes.

- Ce qui est un dilemme que je vis auprès d'étudiants comme de cadres. Soit
je fais mon boulot : je ne cède pas sur ce que je pense être essentiel. Ce
n'est pas très populaire et la crainte s'abat sur moi (et sur mon
banquier). Soit j'adopte une position cynique : vous voulez de la merde, en
voilà sur tartine beurrée. La prochaine, si la rumeur est fondée, ce sera
MS-Office porté sur Linux. Je mets ma tête sur le billot que beaucoup de
linuxiens vont "aimer l'an 2000".

Thierry

[Herve Eychenne]

Nat Makarevitch <n...@linux-france.org> wrote:

>> "Un article du Chicago Tribune
>> Linux n'est-il pas une perte de temps ?"

> à mon sens cet échange relève plutôt de fr.comp.applications.libres, voire
> de fcolm, n ?

Certaines parties relèvent peut-être de fcolm, mais je n'y crois pas trop.
D'autres, franchement de fr.comp.applications.libres, il est vrai.
C'est d'ailleurs le parent pauvre des groupes consacrés de près ou de
loin au logiciel libre. C'est dommage.
Peut-être son statut de groupe modéré fait-il peur à certains ?
Enfin, d'autres parties concerneraient pourquoi pas fr.comp.developpement,
puisqu'il vient de se créer.

>> la question de la perte de temps dans le modèle de développement libre me
>> semble bien réelle:

>> - si la réutilisation de code était massive, une erreur détectée dans
>> un code source pourrait très bien s'être largement propagée

> o, mais sa diffusion même réduit la probabilité de survie du bug car de
> nombreux utilisateurs et développeurs l'emploient de diverses manières. la
> POO est adossée à cette conception (réutilisation, 'généricité' ...), et
> elle donne satisfaction.

Certes. Tout les cas de figure sont possibles.
Mais bon, un exemple frappant est tout de même les recents buffer
overflows identiques trouvés dans bon nombre de serveurs ftp.
Cela prouve que le code a été réutilisé massivement, ce qui est une
bonne chose. Cela dit, tout le monde est encore loin d'avoir remplacé
son serveur ftp bugué par la dernière version.

>> - le logiciel libre n'a pas empêché le développement de deux bureaux
>> comparables tels que Gnome et KDE

> la robustesse d'une espèce découle de sa diversité (lire
> http://www.linux-france.org/article/these/libreevol/), et le nombre de
> découvertes augmente avec celui des impétrants. ne pas négliger, par
> ailleurs, que des projets bien distincts convergent souvent, à terme, y
> compris après la mort de l'un d'eux. cela concerne aussi les logiciels
> commerciaux (examiner l'arbre généalogique des Unix commerciaux).

>> - le polymophisme des applications
>> constitue trop souvent un frein, devant l'accumulation de cas
>> particuliers dans la forme, mais redondants sur le fond;

>> - chacun refait tout de même un peu les mêmes choses dans son coin.

> mais qui jurerait qu'un nouveau projet restera en-déçà du précécent ?

Rien ne permet de le dire à priori, évidemment. Et de toute manière, il
ne s'agit pas de cela. Il s'agit de trouver un moyen d'instaurer un
sorte de couche de dialogue suffisamment universelle pour qu'aucune
évolution ne soit rendue impossible.

> et comment s'assurer qu'il ne bénéficiera pas aux autres ?

Mais cela est généralement le cas.

>> les différentes distributions Linux améliorent leurs procédures
>> d'installation en parallèle, sans que les uns bénéficient directement des
>> avancées des autres

> beaucoup examinent les développements des autres, et s'en inspirent.

Oui, mais au lieu de s'inspirer les uns des autres et de finir au total
avec des procédures incompatibles, ils feraient mieux de s'entendre.

>> Si chacun s'était entendu sur un standard commun (de nivellement par le
>> haut

> si tu penses aux sous-jacents (arbo, fichiers de config ...) cela me semble
> salutaire, et l'inertie projets concernés (LSB ...) m'attriste.

Heureux de te l'entendre dire.

> ns pourrions progresser en mobilisant les utilisateurs, en leur
> détaillant les raisons pour lesquelles ns gagnerions ts à rejeter
> les logiciels ou distributions qui ne les respectent pas.

Exactement. D'ailleurs, certains font déjà cet effort que je qualifierais
volontiers de pédagogique sur les groupes fcol*.
Mais je crains que les futurs utilisateurs (qui arrivent en masse) ne
soient relativement insensibles à de tels arguments.

> mais ne tentont pas d'imposer des normes d'implémentation ou de
> présentation, de factoriser tous les codes. invitons plutôt les
> développeurs à implémenter en respectant les normes et sous forme de
> bibliothèques. leurs pairs et les utilisateurs les emploieront ou n,
> décidant ainsi de l'avenir des projets.

Entièrement d'accord.

>> que d'efforts auraient été épargnés...

> le succès des logiciels libres doit beaucoup (sinon tout) à leur
> qualité.

Pas uniquement. Il y a aussi beaucoup de logiciels commerciaux de
qualité. Cela existe. Evidemment, je ne pense que très peu aux logiciels
venant de Redmond.
Mais les logiciels commerciaux sont souvent d'une finition impeccable,
notamment au niveau graphique. Bien sûr, par en-dessous, c'est toujours
moins joli, mais il ne faut pas négliger l'aspect de la présentation
graphique, qui est tout de même importante et est trop souvent
négligée par les concepteurs logiciels libres, même si cela tend à
s'arranger.

> note : revue des pairs, efforts et projets multiples, découvertes devant
> quasi tout au hasard ...

Sur ce dernier point, je m'interroge... Tu as des exemples en tête ?

> même les auteurs de projets foireux (inutiles, mal conçus ...) y gagnent,
> car il expérimentent, recueillent des commentaires (voire « recherchent les
> causes de l'échec ») ... et apprennent.

Oui. Mais ça, ça ne me chagrine pas. C'est de voir deux développements
parallèles et de tout aussi bon niveau l'un que l'autre finir par
déboucher sur le même produit, qui me dérange déjà un peu plus.

>> l'ensemble de l'ouvrage finit tout de même par prendre forme, mais au
>> prix d'un déploiement d'énergie trop souvent gaspillée.

> connais-tu une autre approche préservant les avantages patents du 'bordel'
> actuel ?

Non. Mais rien n'interdit d'essayer de limiter quelque peu les rares
effets "perverts".

> cela pose des problèmes (pas uniquement d'ordre tech) à ma connaissance non
> résolus à ce jour, mais rien n'interdit de prospecter.

Justement, on touche du doigt le sujet. Quels problèmes "insolubles" ?

>> l'absence d'un architecte garantissant une cohérence d'ensemble se
>> fait parfois cruellement sentir.

> respecter les normes de développement érigées par le projet GNU (tt
> embarquer ds des bibliothèques, donc réduire l'adhérence, et fournir les
> 'liaisons' grâce auxquelles un langage offre à l'utilisateur le moyen de
> conduire et d'étendre l'application) y suffisent, je crois.

Si c'était systématiquement appliqué, ce serait un bon début.

> mieux : on ne peut ménager de grande liberté lorsque même le mode
> d'implémentation est bien spécifié.

J'ai peur de mal comprendre cette phrase (c'est le "même" qui me pose
problème).

> il reste toujours possible, en revanche, d'assurer à un lot de
> logiciels libres une cohérence a posteriori.

Oui, c'est ce que je disais.

>> Le défi crucial est la modularité, ce qui suppose de s'entendre sur
>> une interface respectée par chacun.

> lire la section ''Pas « d'interface standard »'' de
> http://www.linux-france.org/article/presentation/

Certes, vérifier si les gens vont bien lire le pointeur, faire un peu de
pub pour flfo, et économiser un peu de bande passante (quoique... non) est
plus que louable, mais je me permets tout de même de citer ce si court
passage. ;-))

5.9 Pas « d'interface standard »

Le développeur d'application libre est lui-même un spécialiste du
domaine, et réalise une interface correspondant au problème traité et
non à des conventions souvent discutables héritées d'environnements de
bureautique, bien distincts de son champ d'expertise.

Quand je parlais d'interface ici, je pensais beaucoup plus à une interface
de programmation (presqu'au sens Java du terme) qu'à une interface
graphique.

> mieux vaut convenir d'un langage d'extension commun, car cela réduit le
> coût de conception (très élevé, si l'on souhaite réaliser des modules
> directement interopérables) et étend davantage le registre fonctionnel
> (scriptage).

Oui.

> écueil : nombre de béotiens n'apprendront probablement pas ce langage.
> une soluce : clicodrome capable de rédiger des scripts (OK, très
> ambitieux).

En effet. Mais on peut aussi prendre son parti du fait que les programmes
des béotiens ne deviennent réellement intéressants qu'à partir d'un
certain niveau de sophistication.
Et la conversion peut toujours se faire à postériori.

>> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
>> chacune des équipes de développement

> o !

> mais des utilisateurs et n d'une organisation fédératrice.

Oui (pour le non à une organisation fédératrice).
Pour ce qui est des utilisateurs, je suis plus nuancé. Si tu l'entendais
dans le sens "un nombre réduit d'utilisateurs", je suis d'accord.
Car le terme "utilisateurs" regroupe une masse un peu informe qui n'a
pas les moyens de s'organiser (en tant que masse) vraiment pour faire
évoluer des choses d'une nature si pointue.

> cette dernière
> ne serait chargée que de publier des documents résultants de débats publics
> qui détailleraint l'interêt et les modalités de cette approche.

Par exemple...

>> réinventer un peu moins la roue dans son coin, et de s'inscrire
>> immédiatement dans un cadre cohérent.

> lorsque l'on ne sait pas très bien où l'on va ni comment s'y rendre les
> « co-errants » l'emportent sur les « cohérents » :-)

:-))

> « cohérents » au pluriel, o ! car tu négliges peut-être l'importance d'un
> écueil àmha efffrayant : la 'cohérence' de l'un n'est pas celle de
> l'autre.

> les débats (Usenet, listes ...) montrent que mêmes des experts ne
> partagent pas un seul et même avis. obtenir un consensus s'avère
> alors coûteux, et y renoncer condamne l'entreprise.

Oui, mais je pense que tu fais principalement référence aux discussions
sur les systèmes d'exploitation, non ?
Il me semble que les divergences sont rendues possibles par le côté
universel (et donc très général) de ces derniers.
Mais je pense que pour un problème bien défini (ici, un type d'application
bien spécifique), il n'existe pas 36 méthodes efficaces.
Ou s'il existe plusieurs méthodes, chacune conviendra plus particulièrement
à un sous-type de problème.
(Dérive hors-sujet: et la discussion devrait alors porter sur l'occurrence
de tel ou tel cas particulier dans l'ensemble des cas généraux afin de
déterminer la méthode la plus efficace dans la majorité des cas couramments
rencontrés)

Bref, ici, la discussion serait bien ciblée, ce qui diminue les
risques de divergence de vue, s'il on prend le temps de discuter.

> laissons les responsables de projets chercher, choisir, emprunter, rejeter
> ... et les utilisateurs trancher. un peu de confiance en l'homme :-)
> (cet 'humanisme' correspond bien, je crois, à « l'esprit du libre »).

Je fais confiance aux hommes éclairés. L'humanité livrée à elle-même
ne m'inspire pas vraiment confiance. ;-)

RV

--
_
(°= Hervé EYCHENNE : eych...@info.enserb.u-bordeaux.fr
//) E.N.S.E.R.B. : http://www.enserb.u-bordeaux.fr/~eychenne
v_/_

La proportion de gens intelligents parmi les utilisateurs de Linux
est entrain de se réduire fortement. Et le pire, c'est que l'on ne
peut que s'en réjouir.

[Herve Eychenne]

costaclt <cost...@easynet.fr> wrote:

>> Quand je reçois un nouveau produit (qu'il soit logiciel ou non), ma 1ère
>> réaction est de jouer un peu avec, si je vois que je peux tâtonner sans
>> tout "casser".
>> Puis, passé cette période ludique (ou j'ai assimilé une bonne
>> partie des fonctions qui me serviront en utilisation courante), je me
>> plonge dans la doc.

> - Et c'est là que je constate chez la plupart des utilisateurs une

> "rupture" : ils ne passent pas à la seconde étape. J'ai un doute sur l'idée
> de paresse. Je me demande si cela n'a pas à voir avec la crainte.

Mais oui: la crainte de devoir se fatiguer, même les méninges. La paresse,
quoi. ;-)

> Voire la peur qui semble être devenue un moteur social puissant (on
> a peur de perdre son boulot, sa femme, sa base de registre, lilo, la
> face ...).

Il me semble que lire la doc reste la meilleurs protection contre tout
cela. Excepté pour la perte de sa femme, bien entendu. Perte que la lecture
intensive de la doc de lilo semble même favoriser. Allez comprendre... ;-)

> - En ce moment, la guerre est déclarée aux pollueurs de fcolc qui posent
> des questions déjà traitées. Je crois que si ils les posent ces fichues
> FAQ, ce n'est pas par méconnaissance de la netiquette ou des mans.

Si, aussi. Mais ce n'est pas la raison première, en effet.

> C'est la crainte qui dirige ces questions.

La crainte de se faire taper sur les doigts par le comité d'accueil ? ;-)
Je pense plutôt que cela résulte directement de la très jolie société
d'assistanat que nous sommes entrain de développer, où les gens
voudraient que tout leur tombe du ciel, y compris les réponses de ceux
qui ont lu les docs à leur place.

> L'administrateur NT a peur de basculer sur Linux.

La peur de comprendre ce qu'il fait ? ;-)
Mais surtout celle de se faire taper sur les doigts par l'incompétent
qui a fait le choix d'NT à sa place.

> le lycéen a peur de flinguer ses répertoires windows.

Craintes justifiées, s'il en est. ;-)

> C'est le comportement classique de la petite vieille qui emmerde le
> contrôleur SNCF alors que l'information lui est affichée sous le nez
> : il faut qu'une personne identifiable la rassure.

Sauf que dans le cas de Linux, il n'y a pas de personne "identifiable".
Et cela, il est vrai que ça fait peur à certains.

> - La crainte est déjà dans l'intitulé du post initial. Et si effectivement
> Linux n'était qu'une perte de temps ? La crainte de dépenser des heures et
> des espoirs au risque de voir le marché sanctionner ce type de softs. Le
> parcours du linuxien est assez rude...

Il n'en est que plus beau.

> - La crainte générale de celui que l'informatique intéresse. Beaucoup de
> gens se flattent de n'y rien connaître.

C'est parce que l'homme tente son va-tout en essayer de faire passer ses
insuffisances pour des choix personnels.
Genre le type après ses concours: "de toute manière, si j'avais été pris
à l'X, j'y serais pas allé". Si déjà il avait été pris à Centrale, il se
serait jeté dessus.

> Ils subodorent que l'intérêt pour
> l'informatique, et pour linux qui est si peu rentable immédiatement, cache
> quelque chose.

A l'ère de l'instantané et de la rentabilité immédiate, l'investissement
personnel n'a plus sa place.

> On fait souvent référence à la concurrence qui existe entre
> le bidouilleur informatique et ...la compagne.

Et pourtant, c'est bien vrai: la compagnie féminine nuit gravement à
la pratique de l'informatique en général, et au développement du logiciel
libre en particulier. ;-)

> Curieux en effet qu'un domaine professionnel récent, si peu investi
> par définition par des valeurs masculines, n'interesse que très
> modéremment les femmes.

Question que je me suis toujours posée.

> - La crainte qu'occasionne toute lecture. On se plaint des plantades de
> windows. Vu comment il est utilisé dans les entreprises et chez les
> particuliers, cad de manière "pépère", il ne devrait pas planter. Et pour
> peu qu'on lise la doc, il ne plante pas.

La doc qui détaille la liste des actions pourtant licites à ne pas faire ?

> Seulement, une doc, cela commence toujours bien. Puis viennent les
> exceptions aux règles. L'incertitude. On croyait le bidule rationnel
> et bien non, il est aussi compliqué que la vie courante.

On croyait l'informatique rationnelle ? On s'aperçoit qu'avec Microsoft,
elle ne l'est pas.

> Et l'incertitude, vecteur de peur, a mauvaise presse aujourd'hui.

En effet, que de FUD dans la mauvaise presse ! ;-)

>> La bonne nouvelle, c'est qu'il reste (peut-être) encore suffisamment

>> de gens sensés pour sauver les autres d'eux-mêmes.

> - Ce qui est un dilemme que je vis auprès d'étudiants comme de cadres. Soit
> je fais mon boulot : je ne cède pas sur ce que je pense être essentiel. Ce
> n'est pas très populaire et la crainte s'abat sur moi (et sur mon
> banquier).

On a au moins sa conscience pour soi. Et c'est énorme.

> Soit j'adopte une position cynique : vous voulez de la merde, en
> voilà sur tartine beurrée. La prochaine, si la rumeur est fondée, ce sera
> MS-Office porté sur Linux. Je mets ma tête sur le billot que beaucoup de
> linuxiens vont "aimer l'an 2000".

Attention, ils ont peut-être déposé la formule !

RV

--
_
(°= Hervé EYCHENNE : eych...@info.enserb.u-bordeaux.fr
//) E.N.S.E.R.B. : http://www.enserb.u-bordeaux.fr/~eychenne
v_/_

Avant ne vous faire aimer l'an 2000, France Telecom ferait mieux se
faire aimer d'abord. Et c'est pas gagné.

[Michel BILLAUD]

"costaclt" <cost...@easynet.fr> writes:

> Il me semble qu'il y a beaucoup de questions à se poser sur l'origine de
> certains comportements, surtout du fait que ces comportements paraissent
> stéréotypés et transversaux.
>
> - Pourquoi les utilisateurs ne lisent-ils pas la documentation ?
>
> Dans les entreprises, personne ne lit et ne lira jamais une documentation
> papier. Qu'il s'agisse du cadre ou de l'ouvrier, le comportement est
> identique. De rares individus lisent la doc sous forme d'aide intégrée au
> logiciel, mais ils la lisent toujours de manière parcellaire. Pourquoi ? En
> général, les utilisateurs font référence au temps et à l'urgence. Mais
> lorsqu'ils sont en formation, c'est la même chose.

Parce que pour lire la doc, il faut d'abord reconnaitre qu'il va falloir
investir du temps dans de la lecture / de la comprehension / de la mise
en oeuvre de ce qu'on a compris (ou cru comprendre).

> Du reste, beaucoup
> d'étudiants ne lisent pas non plus les docs.

Ils ne lisent pas le journal non plus.

> - Pourquoi les utilisateurs n'utilisent-ils pas leurs softs à plein régime
> ?
>
> Ils utilisent leur voiture "à fond la caisse" mais sous-utilisent leurs
> softs, même s'ils sont toute la journée penchés sur leur ordinateur.

C'etait le sujet de la conversation de la cafet il y a 15 jours :-)
Explication psychologique : schématiquement il y a deux profils
d'utilisateurs, _orientes performance_ (les plus nombreux) et
_orientes perfection_. Ceux de la premiere categorie ne s'interessent
qu'a ce qui permet de resoudre immediatement le probleme concret
qu'ils ont a resoudre maintenant. Les _orientes perfection_ veulent
tout savoir sur le sujet.

On peut etre dans plusieurs categories a la fois, selon le sujet. De nombreux
brillants chercheurs (y compris en informatique) utilisent les outils informatique
de facon totalement déraisonnable (tous leurs fichiers dans le meme repertoire,
pas de sauvegardes etc) alors que dans leur domaine, ils ne negligeraient pas
de jeter un coup d'oeil a _toutes_ les publications, histoire de savoir exactement
cee que tel ou tel eleve de X ou Y fait depuis qu'il est passé dans le labo de Z.

Dans la categorie "utilisations aberrantes", mes etudiants en ont de bonnes :
- primo, changer le window-manager. Celui qui est là par defaut ne peut absolument
pas convenir. En choisir un qui rame.
- mettre des images en fond d'ecran, et aussi en fond des fenetres de textes,
pour ne plus rien y voir, avec des polices minuscules.
- profiter du window manager perfectionne pour avoir constamment UNE fenetre
en plein ecran.
- pour commuter d'une fenetre a l'autre, arreter l'application en
cours, et la relancer. Exemple typique : developpement de
programmes. On lance l'editeur, on tape du texte, on ferme l'editeur,
on ouvre un xterm, on lance la compilation, on voir qu'il y a 5
erreurs, on note le numero de ligne de la premiere,
on referme le xterm, on relance emacs, on corrige et on recommence.
- Bien sur, si l'erreur a lieu a la ligne 123, on tape sur la touche "fleche
vers le bas" 122 fois. Apprendre "esc g 123 (retour)", ca ferait perdre du temps.

> - Pourquoi l'utilisateur souhaite-t-il changer constamment de version de
> soft ?

Serait-ce de la mauvaise conscience, finalement ? En changeant, on
affirme que l'ancien ne convenait pas, ce qui donne a posteriori une
excuse facile pour le peu de productivite qu'on avait avec.

C'est aussi de l'auto-valorisation. J'ai la derniere version, moi,
bande de ploucs.

--
Michel BILLAUD : bil...@labri.u-bordeaux.fr
LABRI - Universite Bordeaux I : phone W: 0556846922 /0556845792
351, cours de la Liberation : http://www.labri.u-bordeaux.fr/~billaud
33405 Talence (FRANCE) : http://dept-info.labri.u-bordeaux.fr/~billaud

[dagerm]

Son avis que lui il a, c'est aussi mon avis a moi que j'ai.
Les distributions distribuent toute la meme soupe et je
prefere avoir 7 WM a choisir que 7 distrib "a tester" avec
l'INTERFACE GRAPHIQUE fvwm1.24 et c'est tout!

Eric Jacoboni a écrit :

> "Stephane TOUGARD" <el...@teaser.fr> writes:
>
> > le seul regret que j'ai avec FreeBSD, c'est son manque
> > d'innovation au niveau des distribs.
>
> Mouais... Finalement, je trouve ça plutôt pas mal, moi. Une seule
> distrib, plusieurs déclinaisons (CURRENT, STABLE, RELEASE) : ça laisse
> de la place pour tout le monde (prudents, pressés, aventureux) et ça
> évite de voir ce que l'on voit sous Linux, des distribs toutes aussi
> incompatibles les unes que les autres, des systèmes de paquetages
> différents, des méthodes de mises à jour différentes, etc.
>
> De toutes façons, à bien y regarder, quels sont les avantages des
> distribs ? Elles contiennent toutes la même chose... Ce qui change,
> c'est le système de paquetage, les choix techniques, la facilité
> d'installation... : on arrive vite à devoir sortir de cet
> emprisonnement pour se peaufiner son système et on a donc créé sa
> propre distrib... Pareil avec FBSD : il y a le truc de base, après on
> installe ses trucs via les ports, ou à la mano si cela n'a pas été
> porté... et quand on y a réussi, on écrit le port, basta.
>
> Cette unicité a, en tous cas, un intérêt : un pb sous FBSD est un pb
> FBSD, alors que souvent les pbs Linux se ramènent à des pbs de
> distribs. Je suis bien placé pour le savoir : écrire une doc quelle
> qu'elle soit pour Linux est un véritable cauchemar car si l'on se base
> sur une distrib, cela ne marchera pas sur une autre (dernier exemple
> en date : PostgreSQL...). On est donc obligé, finalement, de
> s'abstraire de toute distrib pour faire une doc un tant soit peu
> générale et donc exit Linux.
>
> Mon avis à moi que j'ai, en tous cas.
>
> --
> ---------------------------------------------------------
> Éric Jacoboni « No sport, cigars! » (W. Churchill)
> ---------------------------------------------------------

[costaclt]

Michel BILLAUD <bil...@labri.u-bordeaux.fr> a écrit dans l'article
<7z4sluk...@labri.u-bordeaux.fr>...

>
> Parce que pour lire la doc, il faut d'abord reconnaitre qu'il va falloir
> investir du temps dans de la lecture / de la comprehension / de la mise
> en oeuvre de ce qu'on a compris (ou cru comprendre).

- Reconnaître qu'il faut investir du temps, c'est reconnaître qu'il y a une
distance entre le désir et le plaisir. Et que le plaisir est proportionnel
à la distance pour peu qu'on accepte de parcourir le chemin. Ils n'ont
toujours pas appris cela les étudiants ?

- A-priori le plaisir intrinsèque n'est pas privilégié : l'informatique
n'est qu'un moyen d'assurer un pouvoir, elle ne fait pas plaisir en tant
que telle.

- Ce qui manque à l'évidence à ces étudiants : une étude poussée sur le
marivaudage.

> Ils ne lisent pas le journal non plus.

- Moi qui appartiens à la génération "Giscard" je pensais avoir atteint le
sommet de la bétise. Je vois que la génération suivante nous tire la
bourre...

> C'etait le sujet de la conversation de la cafet il y a 15 jours :-)

- Je me disais bien qu'il manquait quelque chose à ce ng : le café !

> Explication psychologique : schématiquement il y a deux profils
> d'utilisateurs, _orientes performance_ (les plus nombreux) et
> _orientes perfection_.

- Et l'alcool...Alcool qui me permet de modifier la catégorisation : les
futurs salauds (ils ont hésité entre des études commerciales et
l'informatique) et les étudiants qui ont un intérêt intrinsèque pour le
domaine. Nous les qualifierons de "bons".

>
> On peut etre dans plusieurs categories a la fois, selon le sujet. De
nombreux
> brillants chercheurs (y compris en informatique) utilisent les outils
informatique
> de facon totalement déraisonnable (tous leurs fichiers dans le meme
repertoire,
> pas de sauvegardes etc) alors que dans leur domaine, ils ne negligeraient
pas
> de jeter un coup d'oeil a _toutes_ les publications, histoire de savoir
exactement
> cee que tel ou tel eleve de X ou Y fait depuis qu'il est passé dans le
labo de Z.

- Je crois que ce n'est pas du même ordre (intrinsèque vs extrinsèque ou
performance vs perfection) : on organise la catastrophe (quand vais-je
dégivrer le frigo ? et l'huile moteur, je la vérifie quand ? etc.). Et il
faut reconnaître une chose : un bon crash du DD et un flingage en règle des
sauvegardes offrent une forme de libération. Maurice Béjart confesse que
lorsqu'il déménage, il abandonne tout. Pas de Deméco chez lui. A l'usage,
je crois que sa méthode est bonne.

>
> Dans la categorie "utilisations aberrantes", mes etudiants en ont de
bonnes :
> - primo, changer le window-manager. Celui qui est là par defaut ne peut
absolument
> pas convenir. En choisir un qui rame.
> - mettre des images en fond d'ecran, et aussi en fond des fenetres de
textes,
> pour ne plus rien y voir, avec des polices minuscules.

- La "customisation" du w-m, phénomène interplanétaire, m'avait d'abord
fait penser à un comportement génétiquement déterminé de marquage du
territoire. Mais cela va toujours dans le sens de l'appauvrissement des
capacités de la machine. Donc je pense maintenant au rituel du handicap
très connu des amateurs de tiercé. La machine doit flancher avant
l'utilisateur. Sinon, on pourrait se rendre compte qu'elle est plus
intéressante que celui qui est censé la gouverner. Bon, on en est pas
encore au stade de "2001" où il faut désactiver la seule entité capable
encore d'éprouver une émotion, HAL, mais progressivement...

> Serait-ce de la mauvaise conscience, finalement ? En changeant, on
> affirme que l'ancien ne convenait pas, ce qui donne a posteriori une
> excuse facile pour le peu de productivite qu'on avait avec.

- Ben oui...

> C'est aussi de l'auto-valorisation. J'ai la derniere version, moi,
> bande de ploucs.

- Et si elle est crackée, c'est encore meilleur. L'ordinateur comme
véhicule de l'image de soi. Dire qu'un simple mirroir suffisait. Un nouveau
champ d'étude donc : le stade de l'ordinateur chez l'adolescent attardé.

Thierry

[Jean-Pierre Sutto]

Michel BILLAUD a écrit:

>
> Parce que pour lire la doc, il faut d'abord reconnaitre qu'il va
> falloir investir du temps dans de la lecture / de la comprehension /
> de la mise en oeuvre de ce qu'on a compris (ou cru comprendre).

Lire une doc n'est-ce pas se remettre en question, remettre en question
ses connaissances, sa compréhension?
Ne pas lire une doc, n'est-ce pas à l'inverse garder la bonne impression
de son intelligence?

--
Jean-Pierre Sutto --+-- Les mots exagèrent. On ne les contrôle plus.

http://perso.wanadoo.fr/jpsutto/photo

[Nat Makarevitch]

Herve Eychenne writes:

>>> - si la réutilisation de code était massive, une erreur détectée dans
>>> un code source pourrait très bien s'être largement propagée

>> o, mais sa diffusion même réduit la probabilité de survie du bug

> un exemple frappant est tout de même les recents buffer overflows

> identiques trouvés dans bon nombre de serveurs ftp

diffusion => 'mieux (que fermeture et secret)', mais pas 'parfait' !

la fermeture complète pose davantage de problèmes (penser aux trous de sécu
de nombreux systèmes propriétaires). en matière de sécurité, d'ailleurs, tt
le monde reconnaît à présent que tt un chacun doit pouvoir examiner le code
(pas de "snake oil"). cet examen améliore la qualité des codes libres, donc
l'intérêt de leur réutilisation.

> tout le monde est encore loin d'avoir remplacé son serveur ftp bugué par
> la dernière version.

o, mais il ne s'agit déjà plus du mm problème car il se pose ds les mm
termes dans le cas d'un code proprio et fermé. des soluces efficaces de
diffusion et d'installation +/- automatisée de codes certifiés et scellés
(garantie d'origine et de contenu) y répondent. 'apt' (Debian) commence à
proposer des services intéressants.

>>> - chacun refait tout de même un peu les mêmes choses dans son coin.

>> mais qui jurerait qu'un nouveau projet restera en-déçà du précécent ?

> Rien ne permet de le dire à priori

il faut donc explorer.

> il ne s'agit pas de cela

il me semble que si. tu doutes de l'intérêt de développer N fois 'la mm
chose', n ? or, selon moi, la 'meilleure' solution parmi un ensemble l'est
souvent d'autant plus que l'ensemble compte d'éléments.

> Il s'agit de trouver un moyen d'instaurer un sorte de couche de dialogue
> suffisamment universelle pour qu'aucune évolution ne soit rendue
> impossible.

'tends, j'ai du mal à suivre :-)
ns 'parlions' de l'intérêt de multiples projets tendus vers un mm objectif,
et voila que tu traites d'une extensibilité absolue. ces deux thèmes me
semblent disjoints : un ensemble logiciel extrêmement souple peut laisser
plusieurs groupes mettre au point autant de solutions à un mm problème
différentes et non interopérables. cas le plus classique : la libc, que
N gus exploiteront de N manières différentes afin de parvenir au mm
résultat si les traitements nécessaires ne sont pas complètement
'triviaux'.

si tu proposes d'étendre autant que possible le champ tout en misant sur
des outils existants seul le MOP offre une soluce, n ? mais son adoption
laisserait pas mal de pain sur la planche pour la plupart d'entre nous !

>> beaucoup examinent les développements des autres, et s'en inspirent.

> au lieu de s'inspirer les uns des autres et de finir au total avec des

> procédures incompatibles, ils feraient mieux de s'entendre.

o, mais les développeurs tentent déjà souvent de le faire. mais il ne faut
pas que cette exigence l'emporte sur la liberté accordée à chacun de juger
son approche plus adéquate, afin de ne pas brider la créativité. qu'ils
discutent, et oeuvrent ensemble s'ils s'entendent ... ou bien forkent !

>> le succès des logiciels libres doit beaucoup (sinon tout) à leur
>> qualité.

> Pas uniquement.

mais « beaucoup » :-)

> Il y a aussi beaucoup de logiciels commerciaux de qualité.

o

> il ne faut pas négliger l'aspect de la présentation graphique, qui est
> tout de même importante et est trop souvent négligée par les concepteurs
> logiciels libres

il faudrait lancer davantage de projets de 'frontalisation/revamping'. et
donc inviter les développeurs à intégrer un langage de scripting ds leurs
logiciels, à concevoir ce dernier sans que l'interface graphique soit le
seul moyen de l'employer, à le réaliser sous forme d'un code liant des
services offerts sous forme de bibliothèques ...

>> découvertes devant quasi tout au hasard ...

> Sur ce dernier point, je m'interroge... Tu as des exemples en tête ?

je pense surtout à mon propre cas. à plusieurs reprises j'ai bricolé des
codes dont je n'ai découvert que par hasard, et pas nécessairement en
furetant à la recherche d'une solution, le moyen de corriger les bugs, ou
les structures de données ou algos adéquats.

> C'est de voir deux développements parallèles et de tout aussi bon niveau
> l'un que l'autre finir par déboucher sur le même produit, qui me dérange
> déjà un peu plus.

tte action unificatrice peut condamner la saine émulation.

>> connais-tu une autre approche préservant les avantages patents du
>> 'bordel' actuel ?

> Non. Mais rien n'interdit d'essayer de limiter quelque peu les rares
> effets "perverts".

les recommandations en vigueur (en particulier 'bibliothèquiser' et «
claquer un langage d'extension ») n'y suffisent pas mais constituent déjà
un progrès important. nul ne dispose des moyens de les rendre obligatoires,
et si c'était le cas nombre de projets pourraient ne pas voir le jour à
cause de cela. (lire aussi, ci-après, « ce ne serait qu'un début ... »)

>>> fournir une bibliothèque de fonctions non interactives, au-dessus de
>>> laquelle seraient bâties les interfaces

>> cela pose des problèmes (pas uniquement d'ordre tech) à ma connaissance

>> non résolus à ce jour, mais rien n'interdit de prospecter.

> Quels problèmes "insolubles" ?

en tt premier lieu le fait que les outils (langages, surtout) les plus en
vogue ne permettent pas vraiment aux logiciels de s'« introspecter ».
l'adoption d'outils plus adéquats rebute nombre d'impétrants. cela me fait
penser au le papier 'worse is better' (pas certain du titre) de Gabriel.

>>> architecte garantissant une cohérence d'ensemble

>> respecter les normes de développement érigées par le projet GNU

> Si c'était systématiquement appliqué, ce serait un bon début.

ce ne serait qu'un début, en effet ... mais nombre de développeurs jugent
encore cela trop coûteux.

>> mieux : on ne peut ménager de grande liberté lorsque même le mode
>> d'implémentation est bien spécifié.

> J'ai peur de mal comprendre cette phrase (c'est le "même" qui me pose
> problème).

quand on va jusqu'à décrire aussi précisément que possible le 'comment', au
lieu de se contenter du 'pourquoi', on bride a priori les développeurs.

>> il reste toujours possible, en revanche, d'assurer à un lot de
>> logiciels libres une cohérence a posteriori.

> Oui, c'est ce que je disais.

ce n'est pas ce que j'avais compris, car tt ton article traitait de
spécification (a priori, donc), et n d'intégration (?)

>> Le développeur d'application libre est lui-même un spécialiste du
>> domaine, et réalise une interface correspondant au problème traité et
>> non à des conventions souvent discutables

> Quand je parlais d'interface ici, je pensais beaucoup plus à une

> interface de programmation (presqu'au sens Java du terme) qu'à une
> interface graphique.

j'étais resté accroché à ton « Par exemple, il deviendrait ainsi possible
de commander le déplacement d'un fenêtre ... ».

mais mon propos reste transposable : comment spécifier les 'signatures'
(méthodes publiques) d'un ensemble de softs dt on ne connaît pas à l'avance
les thèmes, champs d'applications, problèmes traités ? via un super
marshaller de 'sémantique' capable de 'mapper' toutes les actions et
entités modèlisées possibles ? comment procéder sans devoir adosser le tout
à une langue humaine (imprécise et encore mal circonscrite...) ? mm le MOP
('reflection' et consorts ne st que des gadgets à côté de lui) n'offre pas
les ressources nécessaires !

>> mieux vaut convenir d'un langage d'extension commun

> Oui.

o :-)

>> écueil : nombre de béotiens n'apprendront probablement pas ce langage.
>> une soluce : clicodrome capable de rédiger des scripts

> les programmes des béotiens ne deviennent réellement intéressants qu'à

> partir d'un certain niveau de sophistication. Et la conversion peut
> toujours se faire à postériori.

o !!

>>> L'initiative ne peut venir à mon sens que d'une volonté extérieure à
>>> chacune des équipes de développement

>> o !

>> mais des utilisateurs et n d'une organisation fédératrice.

> dans le sens "un nombre réduit d'utilisateurs",

o

>> les débats (Usenet, listes ...) montrent que mêmes des experts ne
>> partagent pas un seul et même avis. obtenir un consensus s'avère alors
>> coûteux, et y renoncer condamne l'entreprise.

> Oui, mais je pense que tu fais principalement référence aux discussions
> sur les systèmes d'exploitation, non ?

pas uniquement : egcs (/gcc), INN (/CNews), X (/NEWS) ...

> Mais je pense que pour un problème bien défini

> il n'existe pas 36 méthodes efficaces.

+/-, o, à une date donnée. mais n, si l'on considère que le temps passe et
que les méthodes s'améliorent, que de nouvelles approches naissent. mais
ces dernières apparaissent parce que certains ont un peu d'avance, on peut
donc penser que l'un des logiciels (visant à résoudre un pb donne) en cours
de développement l'emportera parce qu'il en bénéficie.
ne pas négliger n plus que l'on ne peut ramener l'appréciation de
l'adéquation à celle du niveau d'innovation car un code utile doit disposer
de nombreuses qualités non interdépendantes (bonne implémentation, bonne
doc, source clair et commenté, architecture facilitant la maintenance
adaptative et corrective ...)

> s'il existe plusieurs méthodes, chacune conviendra plus
> particulièrement à un sous-type de problème.
> (Dérive hors-sujet: et la discussion devrait alors porter sur
> l'occurrence de tel ou tel cas particulier dans l'ensemble des cas
> généraux afin de déterminer la méthode la plus efficace dans la majorité
> des cas couramments rencontrés)

serait envisageable si l'on était certain que la nature des problèmes
auxquels on s'attaquera demain sera semblable à celle des défis
d'aujourd'hui.

> la discussion serait bien ciblée, ce qui diminue les risques de
> divergence de vue, s'il on prend le temps de discuter.

d'accord avec cela. mais en pratique les membres de projets n'aiment
souvent pas beaucoup spécifier, ils préfèrent foncer sur leur compilo :-)

>> laissons les responsables de projets chercher, choisir, emprunter,
>> rejeter ... et les utilisateurs trancher. un peu de confiance en l'homme

> Je fais confiance aux hommes éclairés.

qui démontrent la justesse de leurs vues, en matière de développement de
logiciel, grâce à leurs réalisations.

> L'humanité livrée à elle-même ne m'inspire pas vraiment confiance. ;-)

elle filtre elle-même ses artefacts.

[Herve Eychenne]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:

>> tout le monde est encore loin d'avoir remplacé son serveur ftp bugué par
>> la dernière version.

> o, mais il ne s'agit déjà plus du mm problème car il se pose ds les mm
> termes dans le cas d'un code proprio et fermé.

C'est vrai. D'autant plus que le coût du logiciel fermé n'encourage pas
forcément l'achat immédiat d'une nouvelle version.
Je n'irai d'ailleurs pas jusqu'à affirmer que des bugs sont volontairement
introduits dans certains logiciels (quoique... ;-) en vue d'obliger les
utilisateurs à acheter la version "corrigée".

> des soluces efficaces de diffusion et d'installation +/- automatisée
> de codes certifiés et scellés (garantie d'origine et de contenu) y
> répondent. 'apt' (Debian) commence à proposer des services
> intéressants.

Avec à terme une mise à jour complètement automatique (par push) pour
ceux qui le désirent ? Pourquoi pas. Mais cela ne sera pas sans poser
quelques problèmes.

>>> mais qui jurerait qu'un nouveau projet restera en-déçà du précédent ?

>> Rien ne permet de le dire à priori

> il faut donc explorer.

>> il ne s'agit pas de cela

> il me semble que si. tu doutes de l'intérêt de développer N fois 'la mm
> chose', n ? or, selon moi, la 'meilleure' solution parmi un ensemble l'est
> souvent d'autant plus que l'ensemble compte d'éléments.

Oui. Mais il y a d'autres ensembles qui ne comportent encore que très peu
d'éléments (voire aucun), et qu'il serait peut-être bon de remplir
au lieu d'engraisser le cardinal d'autres déjà pas si mal pourvus.

>> Il s'agit de trouver un moyen d'instaurer un sorte de couche de dialogue
>> suffisamment universelle pour qu'aucune évolution ne soit rendue
>> impossible.

> 'tends, j'ai du mal à suivre :-)
> ns 'parlions' de l'intérêt de multiples projets tendus vers un mm
> objectif, et voila que tu traites d'une extensibilité absolue.
> ces deux thèmes me semblent disjoints :

Le vocabulaire ensembliste est décidément à l'honneur ! ;-)
Les deux thèmes sont peut-être disjoints, mais connexes.
Je ne vois pas en quoi le fait de trouver un dénominateur commun à
plusieurs logiciels empêcherait l'extension des possibilités d'un de
ces logiciels. Si l'extension était valable et reconnue comme utile, les
autres l'imiteraient et elle serait sans doute englobée dans le pot
commun.
Au pire, si une extension ne pouvait se faire sans briser le modèle,
rien n'empêche de le faire.
Bien sûr, il ne faudrait pas que l'interface commune soit un carcan auquel
nul ne puisse se soustraire. C'est pour cela qu'il est nécessaire que
le modèle ne soit pas trop gros, car il risquerait de ne plus pouvoir être
contourné. La limitation de ce dernier à chaque petit groupe d'applications
analogues peut garantir cette indépendance.

Cela est en parfait accord avec la pratique du logiciel libre qui
progresse plutôt par couches successives comme on le disait déjà dans
ette enfilade.
Il ne faut pas viser trop haut. L'expérience montre que les projets dont
l'aspect trop ambitieux est marqué dès le début n'attirent pas un grand
nombre de développeurs, accumulent du retard, et finissent par être
dépassés par des projets plus raisonnables.

> un ensemble logiciel extrêmement souple peut laisser
> plusieurs groupes mettre au point autant de solutions à un mm problème
> différentes et non interopérables. cas le plus classique : la libc, que
> N gus exploiteront de N manières différentes afin de parvenir au mm
> résultat si les traitements nécessaires ne sont pas complètement
> 'triviaux'.

Oui. La libc est un exemple un peu trop bas niveau, sans doute.

> si tu proposes d'étendre autant que possible le champ tout en misant sur
> des outils existants seul le MOP offre une soluce, n ?

Oui, exactement. Les méta-objets sont intéressants à plus d'un titre.
Seulement, il faut bien admettre que le monde Linux est plus C que C++,
et il paraît assez délicat de passer à une approche vraiment orientée
objets, qui est pourtant la solution qui paraît la plus efficace et la
moins irréaliste du moment.

Note: il est intéressant de constater que les pères de la théorie du
MOP (CLOS, etc...) travaillent pour la plupart au Xerox PARC, qui a
toujours été un sacré moteur dans le domaine des interfaces (surtout
graphiques ;-).

> mais son adoption laisserait pas mal de pain sur la planche pour la
> plupart d'entre nous !

Oh que oui. C'est sans doute bien trop ambitieux (cf ci-dessus).
Mais d'un côté, on n'a rien sans rien...

>> il ne faut pas négliger l'aspect de la présentation graphique, qui est
>> tout de même importante et est trop souvent négligée par les concepteurs
>> logiciels libres

> il faudrait lancer davantage de projets de 'frontalisation/revamping'. et
> donc inviter les développeurs à intégrer un langage de scripting ds leurs
> logiciels, à concevoir ce dernier sans que l'interface graphique soit le
> seul moyen de l'employer, à le réaliser sous forme d'un code liant des
> services offerts sous forme de bibliothèques ...

Voilà. A ce titre, Gnome est déjà assez intéressant.

>>> découvertes devant quasi tout au hasard ...

>> Sur ce dernier point, je m'interroge... Tu as des exemples en tête ?

> je pense surtout à mon propre cas. à plusieurs reprises j'ai bricolé des
> codes dont je n'ai découvert que par hasard, et pas nécessairement en
> furetant à la recherche d'une solution, le moyen de corriger les bugs, ou
> les structures de données ou algos adéquats.

Je pense que tu as eu de la chance. ;-)
Ah moins que ce ne soit ton génial inconscient qui ait transparu. ;-)

>> C'est de voir deux développements parallèles et de tout aussi bon niveau
>> l'un que l'autre finir par déboucher sur le même produit, qui me dérange
>> déjà un peu plus.

> tte action unificatrice peut condamner la saine émulation.

Mais en quoi le fait d'unifier un minimum les procédures d'intéraction
entre produits empêche-t-il les évolutions ?
Si une amélioration nécessite une rupture avec la couche commune, c'est
que cette dernière n'était pas assez bien conçue, pas assez générale,
voilà tout. Il faudrait donc rediscuter du modèle.

>>> connais-tu une autre approche préservant les avantages patents du
>>> 'bordel' actuel ?

>> Non. Mais rien n'interdit d'essayer de limiter quelque peu les rares
>> effets "perverts".

> les recommandations en vigueur (en particulier 'bibliothèquiser' et «
> claquer un langage d'extension ») n'y suffisent pas mais constituent déjà
> un progrès important. nul ne dispose des moyens de les rendre obligatoires,
> et si c'était le cas nombre de projets pourraient ne pas voir le jour à
> cause de cela. (lire aussi, ci-après, « ce ne serait qu'un début ... »)

Oui, c'est un point à ne pas négliger, tu as raison.

>>>> fournir une bibliothèque de fonctions non interactives, au-dessus de
>>>> laquelle seraient bâties les interfaces

>>> cela pose des problèmes (pas uniquement d'ordre tech) à ma connaissance
>>> non résolus à ce jour, mais rien n'interdit de prospecter.

>> Quels problèmes "insolubles" ?

> en tt premier lieu le fait que les outils (langages, surtout) les plus en
> vogue ne permettent pas vraiment aux logiciels de s'« introspecter ».

J'ai du mal à cerner la chose. ;-)

> l'adoption d'outils plus adéquats rebute nombre d'impétrants. cela me fait

> penser au papier 'worse is better' (pas certain du titre) de Gabriel.

Une référence ?

>>>> architecte garantissant une cohérence d'ensemble

>>> respecter les normes de développement érigées par le projet GNU

>> Si c'était systématiquement appliqué, ce serait un bon début.

> ce ne serait qu'un début, en effet ... mais nombre de développeurs jugent
> encore cela trop coûteux.

Eh bien, le problème, c'est que l'informatique, c'est un métier.
Avec les logiciels libres, tout le monde peut se mettre à la programmation
(même si en pratique, ce sont surtout des informaticiens de formation qui
sont les principaux acteurs). Et tout le monde n'a pas forcément le
baggage nécessaire à la mise en oeuvre de méthodes aussi puissantes
que complexes. Donc, on retombe en quelque sorte sur l'idée de la
réinvention perpétuelle de la roue.
La question sous-jacente est la suivante: le logiciel libre, s'il devient
un acteur principal du marché mondial comme il semble en prendre le chemin,
est-il capable de générer des technologies puissantes qui tireraient
la communauté toute entière vers le haut, sachant que de telles
technologies seraient probablement difficilement accessible à une
population qui constitue jusqu'à présent le sang neuf du mouvement ?

En d'autres termes, n'est-il pas quelque part condamné à demeurer
techniquement limité pour être accessible à tous, et assurer ainsi son
devenir ?

> quand on va jusqu'à décrire aussi précisément que possible le 'comment', au
> lieu de se contenter du 'pourquoi', on bride a priori les développeurs.

Non, pas aussi précisemment que possible. Il faut plutôt fournir un
cadre. A chacun de bâtir autour, sans exclure les aménagements de ce
"cadre", s'ils s'avèrent nécessaires.

>>> il reste toujours possible, en revanche, d'assurer à un lot de
>>> logiciels libres une cohérence a posteriori.

>> Oui, c'est ce que je disais.

> ce n'est pas ce que j'avais compris, car tt ton article traitait de
> spécification (a priori, donc), et n d'intégration (?)

Si tu me relis, j'ai dit en substance que la spécification était à priori
souhaitable, mais que vu l'existant, il ne pouvait s'agir en pratique que
d'une intégration dans la grande majorité des cas.

>>> Le développeur d'application libre est lui-même un spécialiste du
>>> domaine, et réalise une interface correspondant au problème traité et
>>> non à des conventions souvent discutables

>> Quand je parlais d'interface ici, je pensais beaucoup plus à une
>> interface de programmation (presqu'au sens Java du terme) qu'à une
>> interface graphique.

> j'étais resté accroché à ton « Par exemple, il deviendrait ainsi possible
> de commander le déplacement d'un fenêtre ... ».

C'est vrai que c'était trompeur. J'ai d'ailleurs tenté d'insister par
endroits sur cette différence, craignant la confusion. ;-)

> mais mon propos reste transposable : comment spécifier les 'signatures'
> (méthodes publiques) d'un ensemble de softs dt on ne connaît pas à l'avance
> les thèmes,

Pour la spécification, c'est un peu délicat. Pour retravailler une base
existante, c'est déjà moins difficile.

> champs d'applications, problèmes traités ? via un super
> marshaller de 'sémantique' capable de 'mapper' toutes les actions et
> entités modèlisées possibles ? comment procéder sans devoir adosser le tout
> à une langue humaine (imprécise et encore mal circonscrite...) ? mm le MOP
> ('reflection' et consorts ne st que des gadgets à côté de lui) n'offre pas
> les ressources nécessaires !

C'est ce qui arrive quand on essaye de transposer un concept trop général
dans un langage fini.
Mais bon, il ne faut pas perdre espoir et tendre vers l'impossible. ;-)

>>> les débats (Usenet, listes ...) montrent que mêmes des experts ne
>>> partagent pas un seul et même avis. obtenir un consensus s'avère alors
>>> coûteux, et y renoncer condamne l'entreprise.

>> Oui, mais je pense que tu fais principalement référence aux discussions
>> sur les systèmes d'exploitation, non ?

> pas uniquement : egcs (/gcc),

C'est du même ordre. Un compilateur est une application très bas-niveau et
très générale (voir plus bas).

> INN (/CNews), X (/NEWS) ...

Je ne connais pas assez CNews, et ce NEWS (concurrent de X ??) ne me dit
rien du tout. Impossible de donner un avis. :-(

>> Mais je pense que pour un problème bien défini il n'existe pas 36
>> méthodes efficaces.

> +/-, o, à une date donnée. mais n, si l'on considère que le temps passe et
> que les méthodes s'améliorent, que de nouvelles approches naissent.

Quand je parle de méthode pour résoudre un problème donné, je parle
"dans l'absolu"; et non pas de l'état de l'art à un instant donné.
Si une meilleure approche apparaît, il doit être possible de décider
si elle est plus adaptée ou non, pour peu que le problème soit
suffisamment ciblé.
Bien sûr, il y a toujours le conservatisme ambiant dont on peut
difficilement faire fi.

> mais ces dernières apparaissent parce que certains ont un peu
> d'avance, on peut donc penser que l'un des logiciels (visant à
> résoudre un pb donne) en cours de développement l'emportera parce
> qu'il en bénéficie.

Oui.

> ne pas négliger n plus que l'on ne peut ramener l'appréciation de
> l'adéquation à celle du niveau d'innovation car un code utile doit disposer
> de nombreuses qualités non interdépendantes (bonne implémentation, bonne
> doc, source clair et commenté, architecture facilitant la maintenance
> adaptative et corrective ...)

Oui encore. Au pire, la technologie sera reprise, ou le logiciel
amélioré par la communauté.

>> la discussion serait bien ciblée, ce qui diminue les risques de
>> divergence de vue, s'il on prend le temps de discuter.

> d'accord avec cela. mais en pratique les membres de projets n'aiment
> souvent pas beaucoup spécifier, ils préfèrent foncer sur leur compilo :-)

Oh que oui. C'est un tort. Améliorer un programme mal conçu (par absence
de réflexion) revient très souvent à réécrire ce programme quasiment
de bout en bout.

>>> laissons les responsables de projets chercher, choisir, emprunter,
>>> rejeter ... et les utilisateurs trancher. un peu de confiance en l'homme

>> Je fais confiance aux hommes éclairés.

> qui démontrent la justesse de leurs vues, en matière de développement de
> logiciel, grâce à leurs réalisations.

Jusqu'à présent, oui. Mais un esprit brillant sur le plan technique n'est
pas à l'abri d'erreurs de jugement. ;-)

>> L'humanité livrée à elle-même ne m'inspire pas vraiment confiance. ;-)

> elle filtre elle-même ses artefacts.

Mais il n'est pas impossible qu'elle se laisse déborder par elle-même.
Le meilleur moyen de l'éviter étant de rester vigilant... ;-)

RV

--
_
(°= Hervé EYCHENNE : eych...@info.enserb.u-bordeaux.fr
//) E.N.S.E.R.B. : http://www.enserb.u-bordeaux.fr/~eychenne
v_/_

Certes, j'ai trouvé mon bonheur avec Linux. Mais en bon égoïste, cela
ne me satisfait pas: je veux que les autres le partagent !

[Michel BILLAUD]

jean....@wanadoo.fr (Jean-Pierre Sutto) writes:

> Michel BILLAUD a écrit:
> >
> > Parce que pour lire la doc, il faut d'abord reconnaitre qu'il va
> > falloir investir du temps dans de la lecture / de la comprehension /
> > de la mise en oeuvre de ce qu'on a compris (ou cru comprendre).
>
> Lire une doc n'est-ce pas se remettre en question, remettre en question
> ses connaissances, sa compréhension?
> Ne pas lire une doc, n'est-ce pas à l'inverse garder la bonne impression
> de son intelligence?

Il y a un cote "magique" aussi, bien decrit par Pirsig dans le "traite
du Zen et de l'entretien des motocyclettes". Pour le profane, le
mecanicien se contente de donner un coup de clé ici ou là et hop, et
hop ca remarche. (Alors quz le coup de cle est l'aboutissement
d'un processus intellectuel). On peut donc se donner l'impression
d'etre un mecanicien en tapant n'importe ou. Mais en mecanique, on
s'apercoit vite que faire n'importe quoi ne fait pas redemarrer le moteura
ce qui reste l'objectif irrefutable.

En info c'est bien pire : l'informaticien, c'est celui qui tape sur
l'ordinateur. Donc on clique a gauche a droite, il se produit
ceci-cela, du moment que ca a un effet visible, le blaireau est
content. Et plus c'est visible, plus il est content. D'ou l'interet
prononce pour la personnalisation des window-managers: c'est un element de
statut.

A l'epoque des terminaux alphanumeriques, la "maladie infantile de
l'informaticien", c'etait de definir des douzaines d'alias pour pouvoir
taper "l" à la place de "ls" ou avoir un prompt gigantesque avec
l'heure, le nom de la machine et le chemin d'acces, dans des
intensites differentes clignotantes si possible. C'etait quand meme
moins gratifiant, faut reconnaitre.

[costaclt]

Jean-Pierre Sutto <jean....@wanadoo.fr> a écrit dans l'article
<7gktsb$s11$4...@star.kamehameha.fr>...

>
> Lire une doc n'est-ce pas se remettre en question, remettre en question
> ses connaissances, sa compréhension?
> Ne pas lire une doc, n'est-ce pas à l'inverse garder la bonne impression
> de son intelligence?

- Ne pas lire permet aussi de maintenir l'illusion d'un univers de
possibilités à portée de la main. L'informatique porte à l'accumulation (il
n'y a qu'a voir la somme de softs proposée par chaque distribution linux).
D'autre part, on a volontiers la tendance à accumuler des softs ou
utilitaires dont on ne se servira jamais. Pareil pour la doc. Lire de
manière approfondie implique un choix et tout choix restreint par
définition cet univers de possibilités. Qu'il y ait une assimilation de ce
comportement lié à l'informatique avec ce qui relève de la vie en général
me paraît peu douteux.

- Lire de manière approfondie amène à rencontrer un individu. Lorsqu'on lit
une doc, les premiers chapitres donnent toujours l'impression qu'il n'y a
pas "d'auteur". On dit du reste "Avez vous lu la doc sur Emacs?". Ce n'est
que tardivement qu'on peut dire : "Vous avez lu le travail de Welsh et
Kaufman ?". La rencontre avec un auteur semble effrayer : on bascule du
"manuel" vers une affirmation de subjectivité, de choix, de limitation.

- A noter que l'affirmation de la présence d'un auteur me paraît très forte
dans l'univers linux (on lit les how-to d'untel, les Ed O'Reilly placent
très vite la présence de l'auteur par des notes de bas de page). Dans la
doc consacrée aux softs MS, l'auteur semble absent. Les éditeurs, genre MA,
qui essaient de récupérer le marché, ont aussi cette tendance à proposer
des textes sur linux avec un auteur évanescent voire totalement absent.
Cette présence d'auteurs affirmée dans la doc habituelle de linux doit
certainement perturber la personne qui découvre cet os.

- Il y a certainement cette volonté farouche de contempler un univers
organisé, cohérent. Un univers Disney. N'évoque-t-on pas "l'harmonie de la
nature" (alors qu'elle est tout sauf harmonieuse). La lecture approfondie
fait éclater cet univers bien lisse. Cela devient inquiétant. Je vous
suggère la lecture d'un formidable bouquin de Robert Littell, "Le sphinx de
sibérie", dans lequel un informaticien joue sa destinée avec un Cray.

Thierry

[Sam]

costaclt wrote:

> - Lire de manière approfondie amène à rencontrer un individu. Lorsqu'on lit
> une doc, les premiers chapitres donnent toujours l'impression qu'il n'y a
> pas "d'auteur". On dit du reste "Avez vous lu la doc sur Emacs?". Ce n'est
> que tardivement qu'on peut dire : "Vous avez lu le travail de Welsh et
> Kaufman ?". La rencontre avec un auteur semble effrayer : on bascule du
> "manuel" vers une affirmation de subjectivité, de choix, de limitation.

> [...]

> - A noter que l'affirmation de la présence d'un auteur me paraît très forte
> dans l'univers linux (on lit les how-to d'untel, les Ed O'Reilly placent
> très vite la présence de l'auteur par des notes de bas de page). Dans la
> doc consacrée aux softs MS, l'auteur semble absent. Les éditeurs, genre MA,
> qui essaient de récupérer le marché, ont aussi cette tendance à proposer
> des textes sur linux avec un auteur évanescent voire totalement absent.

> Thierry

Oui et c'est justement ça qui fait que les bouquins MA sont
chiants comme la lune pour la plupart (en tout cas ceux que
j'ai lus). On vient pour trouver le savoir, la connaissance,
et on se retrouve devant un mode d'emploi.Bien sûr on y
apprend des choses, mais il manque l'étincelle qui éveillera
vraiment l'interêt du lecteur,qui le passionnera. Je pense
que ça vient effectivement du manque de personnalisation,
mais aussi d'un "polissage" extrème du style. Ils essayent
d'être le plus passe-partout possible, et ils réussissent
bien d'ailleurs.

Tandis que chez O'Reilly, l'auteur place généralement des
petites anecdotes un peu partout, nous raconte ses
déboires,etc. Ca "sent le vécu", on sent que l'auteur sait
de quoi il parle, et on a surtoût le sentiment qu'il a
vraiment envie de faire passer son savoir.
Effectivement, les howtos et autres docs sont aussi
généralement très bien faits, parce qu'il s'agit là encore
de passionnés dont le seul but est de nous faire partager
leurs expériences.

--
<< SPAM, SPAM, SPAM, SPAM saussages and SPAM
I DON'T LIKE SPAM! don't you have something without spam in
it ?
well the eggs with bacon and SPAM does not contains much
spam. >>

[Nat Makarevitch]

Herve Eychenne writes:

>> des soluces efficaces de diffusion et d'installation +/- automatisée
>> de codes certifiés et scellés

> Avec à terme une mise à jour complètement automatique (par push) pour

> ceux qui le désirent ?

o !!

> Mais cela ne sera pas sans poser quelques problèmes.

agir pose un pb, s'en abstenir aussi :-)
seul le choix coûte.

>> tu doutes de l'intérêt de développer N fois 'la mm chose'

>> la 'meilleure' solution parmi un ensemble l'est souvent d'autant plus
>> que l'ensemble compte d'éléments.

> d'autres ensembles qui ne comportent encore que très peu d'éléments

> (voire aucun), et qu'il serait peut-être bon de remplir au lieu
> d'engraisser le cardinal d'autres déjà pas si mal pourvus.

o, mais est-ce seulement possible ?

constat : le développeur-type n'est intéressé que par certains projets et
beaucoup ne souhaitent pas participer s'ils ne connaissent pas le thème
sous-jacent. certains projets (système, graphisme ...) sont donc assez vite
pourvus, mais le reste (gestion ... dommage, d'ailleurs, car sur ce front
aussi on doit pouvoir coder de façon intéressante).

je pose que l'on souhaite satisfaire ts les besoins. une soluce possible :
en appeler au mercenariat (exemple : le Free Software Bazaar). cela crée un
modèle composite de softs libres réalisé selon des modalités apparentées à
celles qui président aux oeuvres commerciales car des utilisateurs
commandent et paient.

>>> Il s'agit de trouver un moyen d'instaurer un sorte de couche de dialogue
>>> suffisamment universelle

>> ns 'parlions' de l'intérêt de multiples projets tendus vers un mm

>> objectif, et voila que tu traites d'une extensibilité absolue.

> Les deux thèmes sont peut-être disjoints, mais connexes.

> Je ne vois pas en quoi le fait de trouver un dénominateur commun à
> plusieurs logiciels empêcherait l'extension des possibilités d'un de
> ces logiciels.

n, au contraire ! mais cette découverte mm n'est souvent possible qu'après
examen des fonctions assurées par le code. tu écris d'ailleurs « à
plusieurs logiciels » plutôt que « à plusieurs cahiers des charges ». il
faudrait donc parvenir à convaincre les développeurs de ces projets de
l'intérêt d'une spécification des services proposés commune à plusieurs
projets par ailleurs distincts et déjà 'matérialisés'. cela peut s'avérer
d'autant plus difficile que ce processus exige souvent des
modifications. ou alors lancer un méta-projet visant à constituer une boîte
noire garante de l'interopérabilité. boulot somme tte assez peu créatif,
donc non gratifiant => peu de volontaires.
pis : tt cela n'est pas envisageable lorsque les approches des concepteurs
sont trop différentes.

> Au pire, si une extension ne pouvait se faire sans briser le modèle,
> rien n'empêche de le faire.

les auteurs ne partageront probablement pas cet avis.

> il ne faudrait pas que l'interface commune soit un carcan auquel nul ne
> puisse se soustraire. C'est pour cela qu'il est nécessaire que le modèle
> ne soit pas trop gros

cette exigence limite son spectre d'application, et limite l'intérêt de la
programmation 'exploratoire' (on code directement, sans trop se soucier de
l'adéquation des structures de données et des algos) qui reste pourtant
l'une des plus prometteuses lorsque l'on souhaite innover. elle implique
une 'table rase'. le développeur peut au besoin gratter en vitesse des
interfaces ad hoc vers d'autres codes, mais un cadre posé a priori peut
restreindre son champ de vision.

> L'expérience montre que les projets dont l'aspect trop ambitieux est
> marqué dès le début n'attirent pas un grand nombre de développeurs

o. sur le plan appliqué il me semble intéressant de constater que les
langages qui n'intègrent pas de riche bibliothèque finissent par en receler
une (C++ : je pense au parcourt (classes NIHCL et apparentées) -> STL) mais
que les développeurs peinent à l'adopter (mauvais pli contracté ? adoption
du langage motivée par son dépouillement même ?).

les langages riches (par ex CL), eux, n'attirent pas les foules. est-ce
parce que le mode de pensée de leurs concepteurs les conduit à les enrichir
ainsi mais reste trop différent de celui des utilisateurs potentiels du
langage ? ou à cause de cette richesse (coût lié à l'apprentissage) même ?

or tt développeur sait bien qu'un outil trop dépouillé le condamne à sans
cesse réinventer la roue.

bref. tt le monde souhaite disposer d'une somme de composants réutilisables
mais quasi personne ne veut la réaliser, et surtout peu se donnent les
moyens de la maîtriser lorsqu'elle existe.

ce paradoxe atteindrait à mon sens les logiciels libres si l'on tentait de
les faire découler d'une somme de micro spécs.

> Les méta-objets sont intéressants à plus d'un titre.
> Seulement, il faut bien admettre que le monde Linux est plus C que C++,

:-))
ah, cela me rappelle la tentative de C++isation du noyau !

seules des projets faisant table rase (par ex www.tunes.org) ou basés sur
une application servant d'environnement pourraient déboucher, je le crains.

> les pères de la théorie du MOP (CLOS, etc...) travaillent pour la plupart
> au Xerox PARC

> moteur dans le domaine des interfaces

o, ts ces thèmes st très interdépendants.

>> tte action unificatrice peut condamner la saine émulation.

> Mais en quoi le fait d'unifier un minimum les procédures d'intéraction
> entre produits empêche-t-il les évolutions ?

interaction => protocole => analyse visant à 'réduire', à décrire les
entités manipulées et fonctions logiques assurées.

si les logiciels existent déjà l'analyse privilégiera les choix des auteurs
du soft le plus apprécié (par exemple : facile à embrasser) par celui qui
la mène. les développeurs des autres logiciels ne pourront donc y adhérer
qu'en rapprochant leurs oeuvres de cette 'référence'. en pratique, même ds
un cas plutôt favorable, ils devront ajouter du code afin de proposer un
mode d'accès à leur soft qui ressemblera étrangement à une 'boîte de
compatibilité' de l'autre projet. une belle unification donne accès à tt,
et beaucoup d'utilisateurs préféreront aborder ts ces outils via cette
interface commune. tt cela confère au logiciel ainsi favorisé un statut
proche de celui d'une implémentation de référence, y compris sur le
terrain, sans lui ôter ses qualités propres. en pratique, à ce stade, les
développeurs de ses 'concurrents' n'ont plus qu'à rejoindre ses auteurs ou
renoncer.

> Si une amélioration nécessite une rupture avec la couche commune, c'est
> que cette dernière n'était pas assez bien conçue

ds certains cas ces révisions abonderaient car les idées foisonnent.

beaucoup de projets naissent d'un fork. il s'agit donc moins de rassembler
des développeurs n'ayant jamais interagi que de renouer des contacts. juste
avant le fork on constate que les conceptions des diverses personnes en
présence divergent trop, surtout en matière de d'évaluation :
1/ - des notions d'« adéquation » et d'« élégance »,
2/ - des priorités (services à assurer ou n ds les plus brefs délais)

2/ est réductible par sondage des populations concernées (users), mais en
pratique cela ne conduit à rien car les développeurs de libre agissent
avant tt pour leur propre satisfaction, et ne st pas corvéables à merci. si
ce n'était pas le cas ts fourgonneraient en ce moment mm sur des applis de
gestion :-)

1/ est vraiment le noeud de l'affaire, et ns ne disposons à ma connaissance
pas d'une méthode de quantification, d'une métrique efficace. lorsque Toto
décide de s'atteler à une soluce bâtie sur/(grâce à) une ressource donnée
(des profondeurs (noyau monolithique ou micro, SMP ou pas ...) jusqu'aux
aspects politiques (utilisation d'une bibliothèque ou d'un langage plus ou
moins 'imparfaitement libre' (Qt, Java ...)) nul ne peut exiger qu'il
articule son développement autour d'une spécs relevant du plus petit commun
dénominateur de l'ensemble des soluces possibles. il peut refuser de
prendre le soin d'ajouter une interface conforme. même s'il accepte on
doutera de sa diligence à cet égard (donc de la qualité du code
correspondant) et les utilisateurs de son logiciel négligeront ce mode
d'exploitation réducteur.

en pratique, à mon sens, tt cela implique que l'on ne peut espérer
spécifier que les entités manipulées, seuls éléments communs non
réducteurs. le protocole d'interface commune doit donc découler d'une
logique de 'transformations'. elle permettra d'exprimer au logiciel que
l'on dispose d'un objet de nature N à convertir en objet N'. => l'interface
pure : une seule méthode : 'type_cl_dest type_cl_src::transform()'. kewl
(et voie ouverte pour les langages d'acteurs, sauf erreur).

écueil : les codes existants ne se prêtent guère à cela, car on voit
nettement se profiler, sous le règne de transform(), une architecture des
codes obligatoirement posée sur des système multi-agents, du blackboard, et
autres bidules du mm tonneau. de la recherche op à la sauce IA,
quoi. gloups. les développeurs vont se faire rares :-)

>>>>> fournir une bibliothèque de fonctions non interactives, au-dessus de
>>>>> laquelle seraient bâties les interfaces

>>>> cela pose des problèmes (pas uniquement d'ordre tech) à ma
>>>> connaissance non résolus à ce jour, mais rien n'interdit de
>>>> prospecter.

>>> Quels problèmes "insolubles" ?

« n résolus » n'est pas <=> « insolubles ».

on ne peut pas espérer spécifier ttes les 'transformations' possibles, il
faut donc laisser à chq code la possibilité d'explorer les autres
dynamiquement. si un soft 'cherche' un traitement par lequel l'un de ses
objets de type T sera transformé en objet de type N il doit être à même de
'décrire' ce qu'est ce N !

adieu les liaisons statiques, on se retrouve en pleine soupe d'objets. que
faire, en runtime, lorsqu'un service (de transformation, ici) nécessaire
n'est pas dispo (pb que posent aussi des langages de la famille C, par
exemple Objective C) ? doit-on confier le routage des requêtes à une
autorité centrale ou bien laisser ts les codes interagir librement ? que
faire en cas de conflit (plus d'un service dispo) ? à tout changement
d'état perceptible de l'extérieur tt soft devra associer une classe, or
certaines transitions sont difficiles à formaliser ainsi (surtout si du
locking ou la notion de 'temps écoulé' s'en mêlent) ... des tonnes de pbs !

>> en tt premier lieu le fait que les outils (langages, surtout) les plus en
>> vogue ne permettent pas vraiment aux logiciels de s'« introspecter ».

> J'ai du mal à cerner la chose. ;-)

grâce à elle un soft pourrait s'enquérir des services offerts par d'autres
codes.

>> l'adoption d'outils plus adéquats rebute nombre d'impétrants. cela me fait
>> penser au papier 'worse is better' (pas certain du titre) de Gabriel.

> Une référence ?

ce n'est pas 'immédiatement' lié à notre propos, mais l'idée développée
correspond fort bien à ma thèse : on peut vouloir faire au mieux, mais en
pratique cela coûte souvent extrêmement cher, donc peu de gens participent.
mm si le rendement est très élevé !

tu l'écrivais ainsi :
=-=-=-=-=-

L'expérience montre que les projets dont l'aspect trop ambitieux est marqué
dès le début n'attirent pas un grand nombre de développeurs

-=-=-=-=-=

la réf : http://www.naggum.no/worse-is-better.html
l'ensemble du site mérite une bonne exploration, d'ailleurs

> l'informatique, c'est un métier.

et la bureautique en est un autre.

> Avec les logiciels libres, tout le monde peut se mettre à la
> programmation

pas uniquement grâce à elle : si j'avais gagné un millimètre de taille à
chq fois qu'un gus m'affirma être un 'développeur de feuilles de calcul' je
ne pourrais plus passer me tenir debout sous la lune.

> tout le monde n'a pas forcément le baggage nécessaire à la mise en oeuvre
> de méthodes

> on retombe

> sur l'idée de la réinvention perpétuelle de la roue

o

> le logiciel libre, s'il devient un acteur principal du marché mondial
> comme il semble en prendre le chemin, est-il capable de générer des
> technologies puissantes qui tireraient la communauté toute entière vers
> le haut

je le crois, car :
- l'émulation joue à plein,
- l'exposition des réalisation (sources) permet à tt un chacun de
progresser à son rythme

> n'est-il pas quelque part condamné à demeurer techniquement limité pour
> être accessible à tous, et assurer ainsi son devenir ?

à mon sens n. car le LL n'est pas homogène. ni par les gabarits, ni par les
orientations, ni par les langages (...). le source du 'ls' des fileutils
est libre, de mm que celui d'Emacs. hacker l'un d'eux est cependant un poil
plus ardu.

>> quand on va jusqu'à décrire aussi précisément que possible le 'comment',
>> au lieu de se contenter du 'pourquoi', on bride a priori les
>> développeurs.

> Non, pas aussi précisemment que possible. Il faut plutôt fournir un
> cadre

peux-tu mieux le circonscrire ? qu'est-ce qui doit être spécifié ?

> Quand je parle de méthode pour résoudre un problème donné, je parle
> "dans l'absolu"; et non pas de l'état de l'art à un instant donné.

le Graal.

>> en pratique les membres de projets n'aiment souvent pas beaucoup
>> spécifier, ils préfèrent foncer sur leur compilo :-)

> Oh que oui. C'est un tort.

tt à fait d'accord, mais l'autre option (gamberger, gamberger ...) est
encore plus dangereuse

> un esprit brillant sur le plan technique n'est pas à l'abri d'erreurs de
> jugement. ;-)

on qualifie généralement ainsi les assertions que l'on ne souhaite pas
partager. pb de mm nature que celui du 1/ ci-devant.

[Astaroth]

Franchement, je ne peux pas laisser passer ça.
Je me demande ce qui est le plus gros chez vous, la tête ou
les chevilles ?
Selon vous, les utilisateurs sont tous des gros cons égoistes et
paresseux ?

Le dim, 02 mai 1999, Herve Eychenne a écrit :

>costaclt <cost...@easynet.fr> wrote:
>
>> - Pourquoi les utilisateurs ne lisent-ils pas la documentation ?
>
>Pour la même raison qu'une majorité de français s'installe devant la
>télé pour regarder Lagaff en rentrant du boulot: la paresse
>intellectuelle.

Non, avant tout, parce que l'informatique, ils s'en foutent,
c'est un outil pour eux, pas un but comme pour vous.
Et les informaticiens dont vous semblez faire partie
s'arrangent souvent pour les les noyer sous des
détails techniques insignifiants, ce qui n'arrange franchement
pas les choses.

>> - Pourquoi les utilisateurs n'utilisent-ils pas leurs softs à plein régime
>> ?
>
>Ils n'utilisent que ce dont ils ont besoin immédiatement.
>C'est de la paresse également. Connaître à fond leur logiciel impliquerait
>de lire la documentation entièrement.

Même réponse. L'outil doit répondre à un besoin. L'option machin
accessible par le menu truc, c'est pas leur problème.
J'ai un très bon ami qui est fana de vidéo.
Pas moi.
Son camescope comporte 2827 touches et il le maitrise parfaitement.
Pas moi.
Quand il me le prête, j'appuies sur un seul bouton et ce que j'arrive
à filmer me suffit amplement
Mais je suis sûrement paresseux.

>> En fait, on leur montre une nouvelle fonctionnalité et ils se
>> découvrent très vite un besoin...

Souvent accessoire et très vite oublié.

>> - POURQUOI l'utilisateur souhaite-t-il changer constamment de version de
>> soft ?

Je ne sais pas sur quelle planète vous vivez, mais ici on est dans une
société dite de consommation. Et il en est de l'informatique comme
des raviolis: on modifie un peu la sauce, on change l'étiquette, on fait
un max de pub et on VEND !!
Le but de la vie est de consommer, toujours plus et de plus en plus vite.
Toute notre économie est basée la-dessus.

>Quand un logiciel est conforme au désir de l'utilisateur, celui-ci n'éprouve
>pas le besoin de changer. Ainsi, j'utilise toujours une vieille Slackware 3.1
>depuis belle lurette. Inutile de vous dire que j'en suis parfaitement
>satisfait, que je ne changerai que lorsque j'éprouverai un manque par
>rapport à une autre version ou distribution.

Un martien, je vous l'avais bien dit !!!

>> - Pourquoi l'utilisateur se passionne-t-il pour des softs qui ne concernent
>> pas son boulot ou ses besoins immédiats ?

Parce que le boulot, pour la majorité des gens, c'est chiant. Combien de
personnes s'éclatent sur leur lieu de travail devant leur traitement de
texte ou leur applis CICS ?

>> Le cadre et l'étudiant adorent les images et les sons.

Ben oui, et alors, où est le mal ?

>> - Pourquoi l'utilisateur adopte-il si tranquillement une position cynique ?
>
>> Il devient rare de trouver des utilisateurs ne maudissant pas MS. Cela ne
>> change rien à leurs choix.

L'utilisateur lambda n'a pas de choix à faire. On lui installe un produit sur
sa bécane, on lui fait une petite formation et roule ma poule, va bosser.
Si ça te ne convient pas, c'est le même tarif.

>> - Pourquoi les utilisateurs en situation professionnelle utilisent-ils des
>> méthodes caduques ?
>
>> Les étudiants sont en général très surpris : ils apprennent des choses
>> sophistiquées et atterrissent dans des entreprises qui travaillent avec des
>> méthodes éculées ( qu'on désigne pudiquement sous le nom "d'expérience du
>> terrain"). Ceci est valable dans tous les secteurs.

J'en ai vu des étudiants tout droit sortis de leurs écoles, la bouche pleine
de théories sur la façon de faire ceci ou cela. Dommage les gars, ici
vous êtes dans le monde du travail, où le mot rendement veut dire
quelque chose, alors oubliez vite fait ce que vos profs vous ont
appris et coulez-vous dans le moule.
Et croyez-moi sur parole, l'expérience du terrain, ça existe et ça
vaut bien quelques théories fumeuses.

>> Pourquoi cet amateurisme ?

Ce n'est pas de l'amateurisme, mais du professionalisme, bien
au contraire. Une entreprise n'est pas un labo de recherche, elle
n'a pas le temps ni la vocation de tester le dernier machin qui vient
de sortir et qui n'a pas encore fait ses preuves. Rentabilité toujours,
les décideurs préfèrent bâtir sur du solide, ou ce qu'il croient être
du solide. La recherche, les formations coûtent chères, le retour
sur investissement doit être immédiat.

>Les gens font ce qu'ils savent faire, et s'y accrochent, même s'il existe
>mieux ailleurs.

Bien sûr, beaucoups de salariés aimeraient faire de la recherche,
beaucoups aimeraient utiliser leur temps à quelque chose
d'intéressant, beaucoups aimeraient nourrir leur famille grâce au
produit de leur passion. Peu sautent le pas, et c'est compréhensible,
il faut payer les traites de la baraque et de la voiture, les fournitures
scolaires, les cadeaux de Noël...

>> - Pourquoi les utilisateurs souhaitent-ils ignorer les enjeux de tout ce
>> qui ne concerne pas directement leur centre d'intéret immédiat ?

Les enjeux de la bagarre entre les fervents de deux OS ???
Quest-ce que vous voulez qu'ils fassent ?

>C'est de l'égoïsme, de l'indifférence, et un grand manque de recul.

Vous-êtes monté au créneau, vous, pour défendre le fromage français
contre les tenants européens du tout pasteurisé ? Et encore, l'exemple
est mal choisi, il est beaucoups plus facile pour un béotien de se rendre
compte des qualités du Roquefort que de Linux...
Alors c'est peut-être "de l'égoïsme, de l'indifférence, et un grand
manque de recul", mais personne n'a l'envie ni le temps de se battre
tout le temps contre tout ce qui ne va pas sur cette Terre.

>L'utilisateur lambda se sert de ce que l'on lui vend, sans trop se
>poser de questions. Il veut quelque chose qui marche à peu près, et
>n'est pas bien exigeant. Quand il pense avoir trouvé ce qu'il lui
>faut, peu lui importe de savoir que le voisin a trouvé mieux que lui
>et qu'il s'est un peu fait avoir. Au contraire, il préférera ignorer
>le voisin et essayera de s'auto-persuader qu'il a pris la bonne
>décision pour ne pas trop "souffrir", allant jusqu'à se mentir à lui-même.

Vous n'avez sûrement jamais acheté de voiture d'occasion, ça se voit.

>... Mais elle décidait tout

>de même d'en acheter un "parce qu'elle n'utilise que Windows et qu'un
>Winmodem est moins cher", en espérant "que tout le monde ne ferait pas
>comme elle".

Ok alors, boycott de tout ce qui n'est pas blanc-bleu ?
D'accord, allons-y

Thomson fait travailler ses cadres au-delà des limites légales et au
mépris des chômeurs. Plus de télé.
http://www.liberation.com/travail/temps/990413.html

Nike exploite des enfants asiatiques. Plus de baskets.
http://www.tao.ca/~direct_ait/auj98216.html

Total et d'autres compagnies pétrolières ont recours à l'esclavage
en Asie. Plus d'essence.
http://www-ilo-mirror.cornell.edu/french/20gb/docs/gb273/myanmar6.htm

Les sociétés pharmaceutiques vendent aux éleveurs bretons des
sédatifs pour calmer les cochons élevés en batterie. Sédatifs
qu'on retrouve inchangés dans l'eau du robinet. Plus de
médicaments. Plus de saucisson.
http://www.rennes.inra.fr/srp/jrp/comite99.html

Les agriculteurs utilisent des semences transgéniques en se
moquant totalement des effets à long terme sur le milieu
écologique. Plus de maïs. Plus de soja.
http://www.lisco.com/FranceTM/genetique3.html

Les américains soutiennent l'incroyable régime intégriste des
Talibans en Afghanistan. Plus de produits américains.
http://services.worldnet.net/~thbzcrt/atheisme/talibans.html

Et on pourrait continuer comme ça pendant des heures.

Je suis persuadé que vous mangez du jambon, que vous
consommez de l'aspirine, que vous emmenez vos gosses
chaussés de leur belles baskets chez McDo dans votre
voiture. Non ?

Hypocrite, ôte premièrement la poutre de ton oeil,
et alors tu verras comment ôter la paille de l'oeil de ton frère.
Luc 6:41 ou Matthieu 7:3, au choix.

[costaclt]

Astaroth <asta...@cybercable.fr> a écrit dans l'article
<925918926....@news.cybercable.fr>...

> Franchement, je ne peux pas laisser passer ça.

Chouette ! Un troll ! (Le but secrêt étant de polluer tellement le groupe
"débats" que même les malpolis renonceront à poser des questions de
configuration et rejoindront enfin fcolc).

Bon les méchancetés s'adressent à André mais comme j'ai un peu poussé au
crime, je réponds le premier.

> Je me demande ce qui est le plus gros chez vous, la tête ou
> les chevilles ?

- Certainement la tête, car pour le sport ce n'est plus tout à fait ça...
Et avec ce que je peux fumer et boire, je dirai que ce qu'il y a de plus
gros chez moi (à part...) c'est sans doute le foie talonné de près par les
poumons.

> Selon vous, les utilisateurs sont tous des gros cons égoistes et
> paresseux ?

- Non !

[La non-lecture de la doc]

> Non, avant tout, parce que l'informatique, ils s'en foutent,
> c'est un outil pour eux, pas un but comme pour vous.

- Je ne suis pas du tout convaincu qu'ils s'en foutent. Il y a plusieurs
preuves à cela : le nombre de bécanes achetées, le nombre et la complexité
des softs achetés (ou empruntés), la multiplication de la presse
informatique (maintenant il y a en gros trois rayons : la presse féminine,
le cul et l'informatique), l'anxiété que cela génère (il "faut" connaître
l'informatique, il "faut" avoir internet at home, il "faut" que mes enfants
ne soient pas à la traîne). Bref, l'ordinateur, ce n'est pas un frigo. Si
la perception n'était que strictement utilitariste, on n'observerai aucun
de ces phénomènes. On a dépassé le stade de l'outil.

> Et les informaticiens dont vous semblez faire partie
> s'arrangent souvent pour les les noyer sous des
> détails techniques insignifiants, ce qui n'arrange franchement
> pas les choses.

- J'aime bien une phrase de R. Barthes : "C'est dans ce qui paraît
insignifiant que se cache la signifiance". A l'usage, c'est tout à fait
valable en informatique. Vous remarquerez que la tendance est tout de même
inverse : on cherche au contraire à masquer ce qui semble être des détails.
Si on pouvait remplacer le clavier par deux ou trois gros boutons, on le
ferait.

[La sous-utilisation des bécanes]

> Même réponse. L'outil doit répondre à un besoin. L'option machin
> accessible par le menu truc, c'est pas leur problème.
> J'ai un très bon ami qui est fana de vidéo.
> Pas moi.
> Son camescope comporte 2827 touches et il le maitrise parfaitement.
> Pas moi.
> Quand il me le prête, j'appuies sur un seul bouton et ce que j'arrive
> à filmer me suffit amplement
> Mais je suis sûrement paresseux.

- Non, vous vous privez d'un grand plaisir. Et vous ne pouvez logiquement
renoncer à des fonctionnalités que si vous les connaissez d'abord. On ne
renonce pas à ce qu'on ne connaît pas.

[La frénésie du changement de softs]

>
> Je ne sais pas sur quelle planète vous vivez, mais ici on est dans une
> société dite de consommation. Et il en est de l'informatique comme
> des raviolis: on modifie un peu la sauce, on change l'étiquette, on fait
> un max de pub et on VEND !!

- L'informatique est le marketing poussé jusqu'à l'horreur. On ne peut que
vous donner raison : la manipulation des désirs est la grande affaire des
sociétés informatiques.

> Le but de la vie est de consommer, toujours plus et de plus en plus
vite.
> Toute notre économie est basée la-dessus.

- Oui. Mais l'agrément de linux et du libre, c'est qu'ils remettent en
cause ce dispositif ou en tout cas l'interrogent.

[L'intérêt pour des softs extérieurs à l'activité principale]

> Parce que le boulot, pour la majorité des gens, c'est chiant. Combien de
> personnes s'éclatent sur leur lieu de travail devant leur traitement de
> texte ou leur applis CICS ?

- Délicat comme situation. D'un côté, recentrer l'utilisateur sur la
compréhension de ce qu'il utilise va lui permettre de prendre plaisir à son
travail. D'un autre, en faisant cela, on le manipule. Il est sain qu'une
personne éprouvant de l'ennui dans son boulot ait une attitude de
contestation.

- C'est d'une grande banalité que d'observer dans les entreprises des
personnes sur-exploitées et sous-payées, qui devraient avoir une attitude
hostile, se réfugier soudainement dans un intérêt suspect pour leur travail
ou pour les machines qu'ils utilisent. Même lors des pauses café, ils
continuent à parler de la presse qui menace à chaque minute de les
transformer en bouillie (le rendement et la sécurité, en France, cela fait
deux). C'est le seul moyen qui leur reste pour tenir le coup : développer
un intérêt artificiel.

[Le culte de l'image et du son chez l'étudiant]

> Ben oui, et alors, où est le mal ?

- Dans le fait qu'il y a de fortes chances qu'il se soit blousé lui-même
dans son orientation professionnelle. En ayant ce type de comportement (qui
est un travail de sape d'un cours), l'étudiant manifeste qu'il y a "quelque
chose qui ne va pas". Ce qui personnellement ne m'étonne pas. Mais je
préfère avoir un comportement coercitif pour qu'à un moment donné la vérité
sur son choix éclate enfin.

[Le cynisme des utilisateurs]

> L'utilisateur lambda n'a pas de choix à faire. On lui installe un produit
sur
> sa bécane, on lui fait une petite formation et roule ma poule, va bosser.
> Si ça te ne convient pas, c'est le même tarif.

- Si il connaissait davantage son matériel, il saurait déjà que des
solutions peut-être meilleures existent. Cela n'entrainerait pas forcément
de réaction immédiate de l'entreprise, mais cela permettrait à
l'utilisateur de ne pas être dans un état de méconnaissance. Cela
l'inclinerait à rouscailler et je pense beaucoup de bien des utilisateurs
un peu déviants.

[La caducité des méthodes employées par les entreprises]

> J'en ai vu des étudiants tout droit sortis de leurs écoles, la bouche
pleine
> de théories sur la façon de faire ceci ou cela. Dommage les gars, ici
> vous êtes dans le monde du travail, où le mot rendement veut dire
> quelque chose, alors oubliez vite fait ce que vos profs vous ont
> appris et coulez-vous dans le moule.
> Et croyez-moi sur parole, l'expérience du terrain, ça existe et ça
> vaut bien quelques théories fumeuses.

- Non, on ne vous croit pas sur parole. Les méthodes utilisées par les
entreprises sont tellement délirantes qu'elles aboutissent à des dépots de
bilan. Regardez les chiffres. On hérite actuellement de dirigeants qui ont
pris place dans les années 70 et dont le niveau technique est
très...modeste. Le coup du "gros bon sens de terrain", cela marchait en
situation de prospérité. Plus maintenant.

- Ce qui est affligeant, c'est que beaucoup de société de conseil leur
vendent de la daube (parce que l'estomac de ces dirigeants ne supporte que
ce plat) et qu'ils continuent à se fourvoyer dans des "nouvelles" méthodes
qui ne sont que des gadgets. Ces dirigeants adorent les fiches-cuisine, les
recettes. Lorsqu'un dirigeant me demande de lui fournir les preuves
chiffrées, voire expérimentales de ce que j'avance, j'en parviendrait même
à lui faire une ristourne...

[Dans la même veine : l'amateurisme]

> Ce n'est pas de l'amateurisme, mais du professionalisme, bien
> au contraire.

- Non.

> Une entreprise n'est pas un labo de recherche, elle
> n'a pas le temps ni la vocation de tester le dernier machin qui vient
> de sortir et qui n'a pas encore fait ses preuves.

- Une entreprise a un département recherche et développement. Sinon ce
n'est pas une entreprise, c'est un "tas".

> Rentabilité toujours,
> les décideurs préfèrent bâtir sur du solide, ou ce qu'il croient être
> du solide. La recherche, les formations coûtent chères, le retour
> sur investissement doit être immédiat.

- Tout à fait d'accord : le regard est toujours porté sur l'extrème
court-terme. Et les différents niveaux hiérarchiques sont menottés par
cette obsession du rendement immédiat. La situation est donc figée.

[L'ignorance des enjeux d'un choix et de ses conséquences]

> Vous-êtes monté au créneau, vous, pour défendre le fromage français
> contre les tenants européens du tout pasteurisé ? Et encore, l'exemple
> est mal choisi, il est beaucoups plus facile pour un béotien de se rendre
> compte des qualités du Roquefort que de Linux...

- Mais oui, on a défendu le fromage français. Bon depuis la lystériose, on
est un peu moins enthousiaste mais le coeur y est...

> Alors c'est peut-être "de l'égoïsme, de l'indifférence, et un grand
> manque de recul", mais personne n'a l'envie ni le temps de se battre
> tout le temps contre tout ce qui ne va pas sur cette Terre.

- D'abord il faut avoir la connaissance des produits, des entreprises et de
leurs organigrammes. Ensuite, on a une marge de liberté, certe restreinte,
mais réelle : Nike en sait quelque chose... Compaq est au courant du
phénomène...MS a eu vent d'un certain courant...

[Liste de sites relatant les diverses infamies que je me permets de laisser
en l'état pour que chacun puisse cliquer sur les url]

- Non : j'ai horreur du jambon qui pisse la flotte, l'aspirine ne me fait
plus rien depuis longtemps, les baskets puent et je ne mange pas une
savatte coincée entre deux éponges. Bon pour la voiture, j'avoue (avec mon
cancer du fumeur, je ne vais pas me déplacer à pinces).

- Mon grand agrément, c'est lorsque je me comporte comme un beauf, qu'une
personne me fasse découvrir ce qu'est un bon vin, un bon bouquin, un bon
film, un bon pont transbordeur, un bon système hydraulique... Parce que
cela me fait plaisir ! Et j'adore à mon tour dévoiler aux autres tout le
plaisir que peuvent apporter certaines choses qu'ils ignorent. Cela peut
être de l'informatique comme de l'escalade.

> Hypocrite, ôte premièrement la poutre de ton oeil,
> et alors tu verras comment ôter la paille de l'oeil de ton frère.
> Luc 6:41 ou Matthieu 7:3, au choix.
>

- Là cela tombe mal car mon sujet de boycott favori est le pape !

Thierry

[devivie . enserb . u-bordeaux . fr]

Astaroth <asta...@cybercable.fr> wrote:
|Franchement, je ne peux pas laisser passer ça.

No passaran !

|Je me demande ce qui est le plus gros chez vous, la tête ou
|les chevilles ?

Let start Yet Another Flame War...

|Selon vous, les utilisateurs sont tous des gros cons égoistes et
|paresseux ?

Avez-vous bien lu ce qu'il a écrit ?

|Non, avant tout, parce que l'informatique, ils s'en foutent,
|c'est un outil pour eux, pas un but comme pour vous.
|Et les informaticiens dont vous semblez faire partie
|s'arrangent souvent pour les les noyer sous des
|détails techniques insignifiants, ce qui n'arrange franchement
|pas les choses.

Le problème c'est que la technique n'a pas eut le temps d'être
assimiler. Tout le monde se met plus ou moins à l'informatique
et peu sont ceux qui maitrisent cette outil d'où l'agacement de
certains vis-à-vis de ceux qui ne réflechissent pas avant de poser
des questions. Noyer son interlocuteur dans un discours abscon et
effectivement une issue qui fait école sur ce ng.

|Je ne sais pas sur quelle planète vous vivez, mais ici on est dans une
|société dite de consommation. Et il en est de l'informatique comme
|des raviolis: on modifie un peu la sauce, on change l'étiquette, on fait
|un max de pub et on VEND !!

Il doit la vivre avec d'autres ideaux...

|Le but de la vie est de consommer, toujours plus et de plus en plus vite.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Flagrant délit de généralisation !

|>> - Pourquoi l'utilisateur se passionne-t-il pour des softs qui ne concernent
|>> pas son boulot ou ses besoins immédiats ?

|Parce que le boulot, pour la majorité des gens, c'est chiant. Combien de
|personnes s'éclatent sur leur lieu de travail devant leur traitement de
|texte ou leur applis CICS ?

Etes vous vraiement sûr qu'il s'agit d'une majorité ?

|L'utilisateur lambda n'a pas de choix à faire. On lui installe un produit sur
|sa bécane, on lui fait une petite formation et roule ma poule, va bosser.
|Si ça te ne convient pas, c'est le même tarif.

L'utilisateur serait donc un être passif qui subirait. Quel drôle état
d'esprit !

|J'en ai vu des étudiants tout droit sortis de leurs écoles, la bouche pleine
|de théories sur la façon de faire ceci ou cela. Dommage les gars, ici
|vous êtes dans le monde du travail, où le mot rendement veut dire
|quelque chose, alors oubliez vite fait ce que vos profs vous ont
|appris et coulez-vous dans le moule.

Ainsi va le destin de notre être passif....

|Hypocrite, ôte premièrement la poutre de ton oeil,
|et alors tu verras comment ôter la paille de l'oeil de ton frère.
|Luc 6:41 ou Matthieu 7:3, au choix.

"Prends-toi en main,
c'est ton destin !"

j.

--
Jerome de Vivie -- ENSERB dept info, //

[Arnaud Gomes-do-Vale]

Bonsoir,

Astaroth <asta...@cybercable.fr> writes:

> Non, avant tout, parce que l'informatique, ils s'en foutent,
> c'est un outil pour eux, pas un but comme pour vous.

Personnellement, quand j'ai besoin d'un outil, j'apprends à m'en
servir. Je ne vois pas pourquoi l'informatique serait une exception.

> Je ne sais pas sur quelle planète vous vivez, mais ici on est dans une
> société dite de consommation.

Hélas...

> Et il en est de l'informatique comme des raviolis: on modifie un peu
> la sauce, on change l'étiquette, on fait un max de pub et on VEND !!

Forcément, tant qu'on trouve des gogos pour acheter...

> Le but de la vie est de consommer, toujours plus et de plus en plus vite.
> Toute notre économie est basée la-dessus.

Et c'est pour ça qu'il faut s'en satisfaire?

> >j'utilise toujours une vieille Slackware 3.1 depuis belle
> >lurette. Inutile de vous dire que j'en suis parfaitement satisfait,
> >que je ne changerai que lorsque j'éprouverai un manque par rapport
> >à une autre version ou distribution.
>
> Un martien, je vous l'avais bien dit !!!

Non, quelqu'un qui réfléchit au lieu de répéter les conneries du
voisin.

Au passage, au début de ton message, tu dis que l'informatique est un
outil. Ici, tu sembles sous-entendre qu'il est essentiel d'avoir
toujours "ce qui se fait de mieux" (comprendre le dernier gadget à la
mode). Il faudrait savoir. Tu changes de tournevis, de voiture où de
fourchette à chaque fois qu'un nouveau modèle sort?

> L'utilisateur lambda n'a pas de choix à faire. On lui installe un produit sur
> sa bécane, on lui fait une petite formation et roule ma poule, va bosser.
> Si ça te ne convient pas, c'est le même tarif.

Pipeau. Si ça ne te convient pas, tu utilises autre chose où tu
n'utilises pas. Attention, je ne parle pas ici du cadre professionnel,
mais bel et bien personnel. La secrétaire pour qui toute l'utilisation
de l'informatique se résume à Word et Excel au boulot ne passe pas son
temps à cracher "FuCk M$ c dE L4 DOb". Le beauf moyen qui s'acharne à
claquer la moitié de sa paie pour avoir le dernier machin qu'il a vu
dans PC Achat, par contre, ne s'en prive pas. Lequel des deux a le
choix, à ton avis?

> >> - Pourquoi les utilisateurs souhaitent-ils ignorer les enjeux de tout ce
> >> qui ne concerne pas directement leur centre d'intéret immédiat ?
>
> Les enjeux de la bagarre entre les fervents de deux OS ???

Non. Les enjeux du logiciel libre, et par la même de la liberté de
l'information (au sens large). Tu peux choisir de t'y interesser ou
non, mais tu ne peux pas ignorer l'existence même de ces enjeux.

--
Arnaud Gomes-do-Vale -*-*-*- arn...@carrosse.frmug.org
http://www.chez.com/gomesdv/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
En savoir plus sur Linux: http://www.linux-france.org

[Herve Eychenne]

Astaroth <asta...@cybercable.fr> wrote:

> Selon vous, les utilisateurs sont tous des gros cons égoistes et
> paresseux ?

Le mot "cons" est en trop. ;-)

> Le dim, 02 mai 1999, Herve Eychenne a écrit :

>>costaclt <cost...@easynet.fr> wrote:

>>> - Pourquoi les utilisateurs ne lisent-ils pas la documentation ?

>>Pour la même raison qu'une majorité de français s'installe devant la
>>télé pour regarder Lagaff en rentrant du boulot: la paresse
>>intellectuelle.

> Non, avant tout, parce que l'informatique, ils s'en foutent,
> c'est un outil pour eux, pas un but comme pour vous.

Entièrement d'accord.

> Et les informaticiens dont vous semblez faire partie s'arrangent
> souvent pour les les noyer sous des détails techniques
> insignifiants, ce qui n'arrange franchement pas les choses.

L'informatique est souvent trop compliquée, je suis le premier à le dire.
Mais elle est parfois aussi trop simple. Je m'explique.
Linux est trop compliqué, dans le sens où la masse des fonctionnalités
offertes noie quelque peu les utilisateurs.
Mais il existe aussi une informatique trop réductrice, qui sous le prétexte
de permettre de faire des choses simples, empêche du même coup les
utilisateurs plus compétents de faire ce qu'ils veulent.

Aucun système d'exploitation n'incarne encore un juste milieu.
Linux pourra dans l'avenir réconcilier les deux types d'utilisation.
Windows ne le pourra jamais, car il est bâti dans le mauvais sens,
de haut en bas.

>>> - Pourquoi les utilisateurs n'utilisent-ils pas leurs softs à plein régime
>>> ?

>>Ils n'utilisent que ce dont ils ont besoin immédiatement.
>>C'est de la paresse également. Connaître à fond leur logiciel impliquerait
>>de lire la documentation entièrement.

> Même réponse. L'outil doit répondre à un besoin. L'option machin
> accessible par le menu truc, c'est pas leur problème.
> J'ai un très bon ami qui est fana de vidéo.
> Pas moi.
> Son camescope comporte 2827 touches et il le maitrise parfaitement.
> Pas moi.
> Quand il me le prête, j'appuies sur un seul bouton et ce que j'arrive
> à filmer me suffit amplement
> Mais je suis sûrement paresseux.

J'ai aussi un ami qui a une HP48. Il est loin d'être manchot, mais quand
je lui montre un truc qu'il ignore, il est toujours entousiamé, et il
finit par l'utiliser couramment. Mais il ne viendra pas à l'idée de
lire le manuel dans son ensemble pour faire le tri par lui-même.
Car toutes les fonctionnalités offertes d'un produit ne sont jamais
intéressantes dans leur ensemble pour un utilisateur donné.
Seulement, certains sauront parcourir le manuel pour savoir ce qui leur
convient. Car les fonctionnalités d'un produit complet dépassent souvent
les attentes de l'utilisateur. Elles créent des besoins, mais elles ne
sont pas présentes par hasard.
Ceux qui n'auront pas lu le manuel seront condamnés à n'utiliser qu'1 %
des capacités fournies. Ils sont les premiers à regretter de n'avoir
pas su faire quelque chose avec quand ils en auraient eu besoin.

>>> En fait, on leur montre une nouvelle fonctionnalité et ils se
>>> découvrent très vite un besoin...

> Souvent accessoire et très vite oublié.

Certaines oui, d'autres non. Et même l'utilisateur ne peut le savoir
à priori.

>>> - POURQUOI l'utilisateur souhaite-t-il changer constamment de version de
>>> soft ?

> Je ne sais pas sur quelle planète vous vivez, mais ici on est dans une
> société dite de consommation. Et il en est de l'informatique comme
> des raviolis: on modifie un peu la sauce, on change l'étiquette, on fait
> un max de pub et on VEND !!
> Le but de la vie est de consommer, toujours plus et de plus en plus vite.

Il y a des gens qui ont un autre but dans la vie que de participer à la
folie frénétique ambiante.

>>Quand un logiciel est conforme au désir de l'utilisateur, celui-ci n'éprouve
>>pas le besoin de changer. Ainsi, j'utilise toujours une vieille Slackware 3.1
>>depuis belle lurette. Inutile de vous dire que j'en suis parfaitement
>>satisfait, que je ne changerai que lorsque j'éprouverai un manque par
>>rapport à une autre version ou distribution.

> Un martien, je vous l'avais bien dit !!!

Je ne vois pas en quoi le fait d'utiliser une distribution Linux qui date
au moins de 2 ans fait de moi un martien.
J'ai testé la Redhat 6.0 (pas chez moi), et elle me semble très correcte.
Seulement, elle a tendance à s'étaler un peu.

>>> - Pourquoi l'utilisateur se passionne-t-il pour des softs qui ne concernent
>>> pas son boulot ou ses besoins immédiats ?

> Parce que le boulot, pour la majorité des gens, c'est chiant. Combien de
> personnes s'éclatent sur leur lieu de travail devant leur traitement de
> texte ou leur applis CICS ?

Beaucoup de gens s'ennuient au travail. Vu le temps que l'on y passe,
je les plains profondément.

>>> - Pourquoi l'utilisateur adopte-il si tranquillement une position cynique ?
>>
>>> Il devient rare de trouver des utilisateurs ne maudissant pas MS. Cela ne
>>> change rien à leurs choix.

> L'utilisateur lambda n'a pas de choix à faire.

Si. Un choix de consommateur.

> On lui installe un produit sur sa bécane,

Là est le problème. En lui pré-installant Windows, on l'empêche de faire
ce choix, ou pire encore, on lui évite de se poser la question de savoir
s'il dispose du meilleur produit.

>>> - Pourquoi les utilisateurs en situation professionnelle utilisent-ils des
>>> méthodes caduques ?

>>> Les étudiants sont en général très surpris : ils apprennent des choses
>>> sophistiquées et atterrissent dans des entreprises qui travaillent avec des
>>> méthodes éculées ( qu'on désigne pudiquement sous le nom "d'expérience du
>>> terrain"). Ceci est valable dans tous les secteurs.

> J'en ai vu des étudiants tout droit sortis de leurs écoles, la bouche pleine
> de théories sur la façon de faire ceci ou cela. Dommage les gars, ici
> vous êtes dans le monde du travail, où le mot rendement veut dire
> quelque chose, alors oubliez vite fait ce que vos profs vous ont
> appris et coulez-vous dans le moule.
> Et croyez-moi sur parole, l'expérience du terrain, ça existe et ça
> vaut bien quelques théories fumeuses.

>>> Pourquoi cet amateurisme ?

> Ce n'est pas de l'amateurisme, mais du professionalisme, bien
> au contraire. Une entreprise n'est pas un labo de recherche, elle
> n'a pas le temps ni la vocation de tester le dernier machin qui vient
> de sortir et qui n'a pas encore fait ses preuves.

<mode facilité>
Entièrement d'accord. Windows 2000 n'a pas encore fait ses preuves (et
ne les fera sans doute jamais), que des milliers d'entreprises se battent
pour faire partie de la première charrette de testeurs.
</mode facilité>

> Rentabilité toujours, les décideurs préfèrent bâtir sur du solide,
> ou ce qu'il croient être du solide. La recherche, les formations
> coûtent chères, le retour sur investissement doit être immédiat.

Une fois encore, Dieu merci, il y a encore sur Terre des gens qui ont
d'autres motivations que le mercantilisme et le profit immédiat.
Il faut de tout.

>>Les gens font ce qu'ils savent faire, et s'y accrochent, même s'il existe
>>mieux ailleurs.

> Bien sûr, beaucoups de salariés aimeraient faire de la recherche,
> beaucoups aimeraient utiliser leur temps à quelque chose
> d'intéressant, beaucoups aimeraient nourrir leur famille grâce au
> produit de leur passion. Peu sautent le pas, et c'est compréhensible,
> il faut payer les traites de la baraque et de la voiture, les fournitures
> scolaires, les cadeaux de Noël...

C'est sans doute vrai. Mais je parlais du point de vue technique...

>>C'est de l'égoïsme, de l'indifférence, et un grand manque de recul.

> Vous-êtes monté au créneau, vous, pour défendre le fromage français
> contre les tenants européens du tout pasteurisé ?

Ce n'est pas ma spécialité. Ma seule arme en la matière et mon pouvoir
de consommateur: j'achète ou je n'achète pas. En l'occurence, je n'achète
que du fromage français.

> Et encore, l'exemple
> est mal choisi, il est beaucoups plus facile pour un béotien de se rendre
> compte des qualités du Roquefort que de Linux...
> Alors c'est peut-être "de l'égoïsme, de l'indifférence, et un grand
> manque de recul", mais personne n'a l'envie ni le temps de se battre
> tout le temps contre tout ce qui ne va pas sur cette Terre.

On ne peut pas être un éternel révolté. Mais il y a un juste milieu.
Si les gens étaient un peu moins indifférents à ce par quoi ils ne se
sentent pas directement concernés (alors que bien souvent ils le sont
tout de même, sans en avoir pris conscience), il y aurait moins de
problèmes.
L'indifférence, c'est quelque part de la complicité.

>>L'utilisateur lambda se sert de ce que l'on lui vend, sans trop se
>>poser de questions. Il veut quelque chose qui marche à peu près, et
>>n'est pas bien exigeant. Quand il pense avoir trouvé ce qu'il lui
>>faut, peu lui importe de savoir que le voisin a trouvé mieux que lui
>>et qu'il s'est un peu fait avoir. Au contraire, il préférera ignorer
>>le voisin et essayera de s'auto-persuader qu'il a pris la bonne
>>décision pour ne pas trop "souffrir", allant jusqu'à se mentir à lui-même.

> Vous n'avez sûrement jamais acheté de voiture d'occasion, ça se voit.

Justement ! Si l'utilisateur de produits informatiques avait la même
exigeance de qualité qu'en matière de voitures d'occasion, on n'en serait
pas là où on en est aujourd'hui.

>>... Mais elle décidait tout
>>de même d'en acheter un "parce qu'elle n'utilise que Windows et qu'un
>>Winmodem est moins cher", en espérant "que tout le monde ne ferait pas
>>comme elle".

> Ok alors, boycott de tout ce qui n'est pas blanc-bleu ?
> D'accord, allons-y

Ben oui.

> Thomson fait travailler ses cadres au-delà des limites légales et au
> mépris des chômeurs. Plus de télé.
> http://www.liberation.com/travail/temps/990413.html

Si les chômeurs étaient capables d'accomplir ce que font les cadres
de Thompson et autres (car tous dépassent largement les horaires
prévus par la loi), ça se saurait. Ce sont ces gens-là qui portent à
bout de bras la technologie française. Puisque vous avez l'air fasciné
par la société de consommation, je peux rentrer dans votre jeu.
Brider ces entreprises pour créer au final des emplois peu qualifiés,
c'est entamer gravement la compétitivité des entreprises françaises, et
à terme produire plus de chômeurs.

> Nike exploite des enfants asiatiques. Plus de baskets.
> http://www.tao.ca/~direct_ait/auj98216.html

Je n'achète pas de Nike.

> Total et d'autres compagnies pétrolières ont recours à l'esclavage
> en Asie. Plus d'essence.
> http://www-ilo-mirror.cornell.edu/french/20gb/docs/gb273/myanmar6.htm

Je n'ai pas de voiture. Mais qu'en j'en aurai une, vu cette intéressante
précision, et je viendrai plus chez eux, et pas par hasard. ;-)

> Les sociétés pharmaceutiques vendent aux éleveurs bretons des
> sédatifs pour calmer les cochons élevés en batterie. Sédatifs
> qu'on retrouve inchangés dans l'eau du robinet. Plus de
> médicaments. Plus de saucisson.
> http://www.rennes.inra.fr/srp/jrp/comite99.html

A-t-on le choix ? Est-on informé de la chose sur l'étiquette ?
Si ça se trouve, tout le monde fait la même chose, en plus.
Le consommateur est ici impuissant.
Seul le bon sens (mais là il ne faut pas trop y compter) des firmes
pharmaceutiques et des éleveurs, ou l'état (sans majuscule), dont c'est
pourtant le rôle, pourraient faire quelque chose.

> Les agriculteurs utilisent des semences transgéniques en se
> moquant totalement des effets à long terme sur le milieu
> écologique. Plus de maïs. Plus de soja.
> http://www.lisco.com/FranceTM/genetique3.html

Même problème.

> Les américains soutiennent l'incroyable régime intégriste des
> Talibans en Afghanistan. Plus de produits américains.
> http://services.worldnet.net/~thbzcrt/atheisme/talibans.html

Mise à part la généralisation abusive aux produits américains d'un
choix politique clairement condamnable, il est clair que je suis tout
sauf un fervent admirateur de la culture américaine. Je boycotte un
maximum de leur super-productions stupides, je ne vais pour ainsi dire
jamais au fast-food, je ne construit pas ma vie autour de l'argent,
etc...

> Et on pourrait continuer comme ça pendant des heures.

Oui, mais ce ne serait pas conforme au sujet du groupe.

> Je suis persuadé que vous mangez du jambon,

Pas des masses, mais bon... ;-)
Si je voyais un jambon dont on puisse garantir qu'il ne provient pas
de cochons gavés de produits en tout genre, je serais tout à fait prêt
à l'acheter.

> que vous consommez de l'aspirine,

J'ai très rarement mal à la tête. ;-)

> que vous emmenez vos gosses chaussés de leur belles baskets chez
> McDo dans votre voiture. Non ?

Il se trouve que je n'ai pas encore d'enfants. Mais je n'envisage pas
vraiment pas de les laisser se promener avec des baskets au pieds toute
la sainte journée. Et je les emmenerai partout sauf au MacDo pour manger.

> Hypocrite, ôte premièrement la poutre de ton oeil,
> et alors tu verras comment ôter la paille de l'oeil de ton frère.
> Luc 6:41 ou Matthieu 7:3, au choix.

Non, vraiment. Il n'y a pas deux poids deux mesures, en ce qui me concerne.
Je fais les choix que je peux faire, mais je les fais sans me soucier
du fait que les autres fassent les mêmes ou pas.
On peut toujours se dire que ça ne sert à rien, mais il faut voir un peu
plus loin que le bout de son nez. Dans le même ordre d'idée, beaucoup
de gens ne vont pas voter parce qu'ils pensent que ce n'est pas leur
toute petite voix qui va changer grand'chose. Si tout le monde tenait le
même raisonnement, il y aurait 100% d'abstention aux élections.

[Herve Eychenne]

Astaroth <asta...@cybercable.fr> wrote:

> Selon vous, les utilisateurs sont tous des gros cons égoistes et
> paresseux ?

Le mot "cons" est en trop. ;-)
Sinon, pas tous. Mais il y en a un nombre non négligeable.
Il n'y a qu'à voir les groupes fcol* pour s'en convaincre.

> Le dim, 02 mai 1999, Herve Eychenne a écrit :

>>costaclt <cost...@easynet.fr> wrote:

>>> - Pourquoi les utilisateurs ne lisent-ils pas la documentation ?

>>Pour la même raison qu'une majorité de français s'installe devant la
>>télé pour regarder Lagaff en rentrant du boulot: la paresse
>>intellectuelle.

> Non, avant tout, parce que l'informatique, ils s'en foutent,
> c'est un outil pour eux, pas un but comme pour vous.

Entièrement d'accord.

> Et les informaticiens dont vous semblez faire partie s'arrangent
> souvent pour les les noyer sous des détails techniques
> insignifiants, ce qui n'arrange franchement pas les choses.

L'informatique est souvent trop compliquée, je suis le premier à le dire.

Mais elle est parfois aussi trop simple. Je m'explique.
Linux est trop compliqué, dans le sens où la masse des fonctionnalités
offertes noie quelque peu les utilisateurs.
Mais il existe aussi une informatique trop réductrice, qui sous le prétexte
de permettre de faire des choses simples, empêche du même coup les
utilisateurs plus compétents de faire ce qu'ils veulent.

Aucun système d'exploitation n'incarne encore un juste milieu.
Linux pourra dans l'avenir réconcilier les deux types d'utilisation.
Windows ne le pourra jamais, car il est bâti dans le mauvais sens,
de haut en bas.

>>> - Pourquoi les utilisateurs n'utilisent-ils pas leurs softs à plein régime
>>> ?

>>Ils n'utilisent que ce dont ils ont besoin immédiatement.
>>C'est de la paresse également. Connaître à fond leur logiciel impliquerait
>>de lire la documentation entièrement.

> Même réponse. L'outil doit répondre à un besoin. L'option machin
> accessible par le menu truc, c'est pas leur problème.
> J'ai un très bon ami qui est fana de vidéo.
> Pas moi.
> Son camescope comporte 2827 touches et il le maitrise parfaitement.
> Pas moi.
> Quand il me le prête, j'appuies sur un seul bouton et ce que j'arrive
> à filmer me suffit amplement
> Mais je suis sûrement paresseux.

J'ai aussi un ami qui a une HP48. Il est loin d'être manchot, mais quand

je lui montre un truc qu'il ignore, il est toujours entousiamé, et il
finit par l'utiliser couramment. Mais il ne viendra pas à l'idée de
lire le manuel dans son ensemble pour faire le tri par lui-même.
Car toutes les fonctionnalités offertes d'un produit ne sont jamais
intéressantes dans leur ensemble pour un utilisateur donné.
Seulement, certains sauront parcourir le manuel pour savoir ce qui leur
convient. Car les fonctionnalités d'un produit complet dépassent souvent
les attentes de l'utilisateur. Elles créent des besoins, mais elles ne
sont pas présentes par hasard.
Ceux qui n'auront pas lu le manuel seront condamnés à n'utiliser qu'1 %
des capacités fournies. Ils sont les premiers à regretter de n'avoir
pas su faire quelque chose avec quand ils en auraient eu besoin.

>>> En fait, on leur montre une nouvelle fonctionnalité et ils se

>>> découvrent très vite un besoin...

> Souvent accessoire et très vite oublié.

Certaines oui, d'autres non. Et même l'utilisateur ne peut le savoir
à priori.

>>> - POURQUOI l'utilisateur souhaite-t-il changer constamment de version de
>>> soft ?

> Je ne sais pas sur quelle planète vous vivez, mais ici on est dans une
> société dite de consommation. Et il en est de l'informatique comme
> des raviolis: on modifie un peu la sauce, on change l'étiquette, on fait
> un max de pub et on VEND !!
> Le but de la vie est de consommer, toujours plus et de plus en plus vite.

Il y a des gens qui ont un autre but dans la vie que de participer à la
folie frénétique ambiante.

>>Quand un logiciel est conforme au désir de l'utilisateur, celui-ci n'éprouve

>>pas le besoin de changer. Ainsi, j'utilise toujours une vieille Slackware 3.1
>>depuis belle lurette. Inutile de vous dire que j'en suis parfaitement
>>satisfait, que je ne changerai que lorsque j'éprouverai un manque par
>>rapport à une autre version ou distribution.

> Un martien, je vous l'avais bien dit !!!

Je ne vois pas en quoi le fait d'utiliser une distribution Linux qui date

au moins de 2 ans fait de moi un martien.
J'ai testé la Redhat 6.0 (pas chez moi), et elle me semble très correcte.
Seulement, elle a tendance à s'étaler un peu.

>>> - Pourquoi l'utilisateur se passionne-t-il pour des softs qui ne concernent

>>> pas son boulot ou ses besoins immédiats ?

> Parce que le boulot, pour la majorité des gens, c'est chiant. Combien de
> personnes s'éclatent sur leur lieu de travail devant leur traitement de
> texte ou leur applis CICS ?

Beaucoup de gens s'ennuient au travail. Vu le temps que l'on y passe,
je les plains profondément.

>>> - Pourquoi l'utilisateur adopte-il si tranquillement une position cynique ?

>>
>>> Il devient rare de trouver des utilisateurs ne maudissant pas MS. Cela ne
>>> change rien à leurs choix.

> L'utilisateur lambda n'a pas de choix à faire.

Si. Un choix de consommateur.

> On lui installe un produit sur sa bécane,

Là est le problème. En lui pré-installant Windows, on l'empêche de faire

ce choix, ou pire encore, on lui évite de se poser la question de savoir
s'il dispose du meilleur produit.

>>> - Pourquoi les utilisateurs en situation professionnelle utilisent-ils des
>>> méthodes caduques ?

>>> Les étudiants sont en général très surpris : ils apprennent des choses
>>> sophistiquées et atterrissent dans des entreprises qui travaillent avec des
>>> méthodes éculées ( qu'on désigne pudiquement sous le nom "d'expérience du
>>> terrain"). Ceci est valable dans tous les secteurs.

> J'en ai vu des étudiants tout droit sortis de leurs écoles, la bouche pleine
> de théories sur la façon de faire ceci ou cela. Dommage les gars, ici
> vous êtes dans le monde du travail, où le mot rendement veut dire
> quelque chose, alors oubliez vite fait ce que vos profs vous ont
> appris et coulez-vous dans le moule.
> Et croyez-moi sur parole, l'expérience du terrain, ça existe et ça
> vaut bien quelques théories fumeuses.

>>> Pourquoi cet amateurisme ?

> Ce n'est pas de l'amateurisme, mais du professionalisme, bien
> au contraire. Une entreprise n'est pas un labo de recherche, elle
> n'a pas le temps ni la vocation de tester le dernier machin qui vient
> de sortir et qui n'a pas encore fait ses preuves.

<mode facilité>

Entièrement d'accord. Windows 2000 n'a pas encore fait ses preuves (et
ne les fera sans doute jamais), que des milliers d'entreprises se battent
pour faire partie de la première charrette de testeurs.
</mode facilité>

> Rentabilité toujours, les décideurs préfèrent bâtir sur du solide,

> ou ce qu'il croient être du solide. La recherche, les formations
> coûtent chères, le retour sur investissement doit être immédiat.

Une fois encore, Dieu merci, il y a encore sur Terre des gens qui ont

d'autres motivations que le mercantilisme et le profit immédiat.
Il faut de tout.

>>Les gens font ce qu'ils savent faire, et s'y accrochent, même s'il existe
>>mieux ailleurs.

> Bien sûr, beaucoups de salariés aimeraient faire de la recherche,
> beaucoups aimeraient utiliser leur temps à quelque chose
> d'intéressant, beaucoups aimeraient nourrir leur famille grâce au
> produit de leur passion. Peu sautent le pas, et c'est compréhensible,
> il faut payer les traites de la baraque et de la voiture, les fournitures
> scolaires, les cadeaux de Noël...

C'est sans doute vrai. Mais je parlais du point de vue technique...

> Les enjeux de la bagarre entre les fervents de deux OS ???

> Quest-ce que vous voulez qu'ils fassent ?

Ce que cache la "guerre" entre ces systèmes, ce n'est pas la dernière
fonctionnalité à la mode: c'est un véritable choix de société, et à
long terme ! Mais ça, les gens ne l'ont pas encore compris. Ou alors,
s'ils l'ont compris, ils ne sont pas prêts à faire les sacrifices qu'il
faut pour assurer leur liberté future (un peu comme ma copine avec
son Winmodem). Ca revient au même.
La liberté, ça se mérite.

>>C'est de l'égoïsme, de l'indifférence, et un grand manque de recul.

> Vous-êtes monté au créneau, vous, pour défendre le fromage français
> contre les tenants européens du tout pasteurisé ?

Ce n'est pas ma spécialité. Ma seule arme en la matière et mon pouvoir

de consommateur: j'achète ou je n'achète pas. En l'occurence, je n'achète
que du fromage français.

> Et encore, l'exemple

> est mal choisi, il est beaucoups plus facile pour un béotien de se rendre
> compte des qualités du Roquefort que de Linux...
> Alors c'est peut-être "de l'égoïsme, de l'indifférence, et un grand
> manque de recul", mais personne n'a l'envie ni le temps de se battre
> tout le temps contre tout ce qui ne va pas sur cette Terre.

On ne peut pas être un éternel révolté. Mais il y a un juste milieu.

Si les gens étaient un peu moins indifférents à ce par quoi ils ne se
sentent pas directement concernés (alors que bien souvent ils le sont
tout de même, sans en avoir pris conscience), il y aurait moins de
problèmes.
L'indifférence, c'est quelque part de la complicité.

>>L'utilisateur lambda se sert de ce que l'on lui vend, sans trop se

>>poser de questions. Il veut quelque chose qui marche à peu près, et
>>n'est pas bien exigeant. Quand il pense avoir trouvé ce qu'il lui
>>faut, peu lui importe de savoir que le voisin a trouvé mieux que lui
>>et qu'il s'est un peu fait avoir. Au contraire, il préférera ignorer
>>le voisin et essayera de s'auto-persuader qu'il a pris la bonne
>>décision pour ne pas trop "souffrir", allant jusqu'à se mentir à lui-même.

> Vous n'avez sûrement jamais acheté de voiture d'occasion, ça se voit.

Justement ! Si l'utilisateur de produits informatiques avait la même

exigeance de qualité qu'en matière de voitures d'occasion, on n'en serait
pas là où on en est aujourd'hui.

>>... Mais elle décidait tout

>>de même d'en acheter un "parce qu'elle n'utilise que Windows et qu'un
>>Winmodem est moins cher", en espérant "que tout le monde ne ferait pas
>>comme elle".

> Ok alors, boycott de tout ce qui n'est pas blanc-bleu ?
> D'accord, allons-y

Ben oui.

> Thomson fait travailler ses cadres au-delà des limites légales et au
> mépris des chômeurs. Plus de télé.
> http://www.liberation.com/travail/temps/990413.html

Si les chômeurs étaient capables d'accomplir ce que font les cadres

de Thompson et autres (car tous dépassent largement les horaires
prévus par la loi), ça se saurait. Ce sont ces gens-là qui portent à
bout de bras la technologie française. Puisque vous avez l'air fasciné
par la société de consommation, je peux rentrer dans votre jeu.
Brider ces entreprises pour créer au final des emplois peu qualifiés,
c'est entamer gravement la compétitivité des entreprises françaises, et
à terme produire plus de chômeurs.

> Nike exploite des enfants asiatiques. Plus de baskets.
> http://www.tao.ca/~direct_ait/auj98216.html

Je n'achète pas de Nike.

> Total et d'autres compagnies pétrolières ont recours à l'esclavage

> en Asie. Plus d'essence.
> http://www-ilo-mirror.cornell.edu/french/20gb/docs/gb273/myanmar6.htm

Je n'ai pas de voiture. Mais qu'en j'en aurai une, vu cette intéressante

précision, et je viendrai plus chez eux, et pas par hasard. ;-)

> Les sociétés pharmaceutiques vendent aux éleveurs bretons des

> sédatifs pour calmer les cochons élevés en batterie. Sédatifs
> qu'on retrouve inchangés dans l'eau du robinet. Plus de
> médicaments. Plus de saucisson.
> http://www.rennes.inra.fr/srp/jrp/comite99.html

A-t-on le choix ? Est-on informé de la chose sur l'étiquette ?

Si ça se trouve, tout le monde fait la même chose, en plus.
Le consommateur est ici impuissant.
Seul le bon sens (mais là il ne faut pas trop y compter) des firmes
pharmaceutiques et des éleveurs, ou l'état (sans majuscule), dont c'est
pourtant le rôle, pourraient faire quelque chose.

> Les agriculteurs utilisent des semences transgéniques en se

> moquant totalement des effets à long terme sur le milieu
> écologique. Plus de maïs. Plus de soja.
> http://www.lisco.com/FranceTM/genetique3.html

Même problème.

> Les américains soutiennent l'incroyable régime intégriste des
> Talibans en Afghanistan. Plus de produits américains.
> http://services.worldnet.net/~thbzcrt/atheisme/talibans.html

Mise à part la généralisation abusive aux produits américains d'un

choix politique clairement condamnable, il est clair que je suis tout
sauf un fervent admirateur de la culture américaine. Je boycotte un
maximum de leur super-productions stupides, je ne vais pour ainsi dire
jamais au fast-food, je ne construit pas ma vie autour de l'argent,
etc...

> Et on pourrait continuer comme ça pendant des heures.

Oui, mais ce ne serait pas conforme au sujet du groupe.

> Je suis persuadé que vous mangez du jambon,

Pas des masses, mais bon... ;-)

Si je voyais un jambon dont on puisse garantir qu'il ne provient pas
de cochons gavés de produits en tout genre, je serais tout à fait prêt
à l'acheter.

> que vous consommez de l'aspirine,

J'ai très rarement mal à la tête. ;-)

> que vous emmenez vos gosses chaussés de leur belles baskets chez

> McDo dans votre voiture. Non ?

Il se trouve que je n'ai pas encore d'enfants. Mais je n'envisage pas

vraiment pas de les laisser se promener avec des baskets au pieds toute
la sainte journée. Et je les emmenerai partout sauf au MacDo pour manger.

> Hypocrite, ôte premièrement la poutre de ton oeil,

> et alors tu verras comment ôter la paille de l'oeil de ton frère.
> Luc 6:41 ou Matthieu 7:3, au choix.

Non, vraiment. Il n'y a pas deux poids deux mesures, en ce qui me concerne.

Je fais les choix que je peux faire, mais je les fais sans me soucier
du fait que les autres fassent les mêmes ou pas.
On peut toujours se dire que ça ne sert à rien, mais il faut voir un peu
plus loin que le bout de son nez. Dans le même ordre d'idée, beaucoup
de gens ne vont pas voter parce qu'ils pensent que ce n'est pas leur
toute petite voix qui va changer grand'chose. Si tout le monde tenait le
même raisonnement, il y aurait 100% d'abstention aux élections.

RV

[emmanue...@skynet.be]

On Wed, 5 May 1999 17:37:51 +0200, Astaroth <asta...@cybercable.fr>
wrote:
[je ne reprends pas tout]

>>> - POURQUOI l'utilisateur souhaite-t-il changer constamment de version de
>>> soft ?
>
>Je ne sais pas sur quelle planète vous vivez, mais ici on est dans une
>société dite de consommation. Et il en est de l'informatique comme
>des raviolis: on modifie un peu la sauce, on change l'étiquette, on fait
>un max de pub et on VEND !!
>Le but de la vie est de consommer, toujours plus et de plus en plus vite.
>Toute notre économie est basée la-dessus.
>

>>> - Pourquoi les utilisateurs en situation professionnelle utilisent-ils des

>>> méthodes caduques ?
>>
>>> Les étudiants sont en général très surpris : ils apprennent des choses
>>> sophistiquées et atterrissent dans des entreprises qui travaillent avec des
>>> méthodes éculées ( qu'on désigne pudiquement sous le nom "d'expérience du
>>> terrain"). Ceci est valable dans tous les secteurs.
>
>J'en ai vu des étudiants tout droit sortis de leurs écoles, la bouche pleine
>de théories sur la façon de faire ceci ou cela. Dommage les gars, ici
>vous êtes dans le monde du travail, où le mot rendement veut dire
>quelque chose, alors oubliez vite fait ce que vos profs vous ont
>appris et coulez-vous dans le moule.
>Et croyez-moi sur parole, l'expérience du terrain, ça existe et ça
>vaut bien quelques théories fumeuses.

La théorie et la pratique diffère, ok, mais si l'expérience de terrain
n'est jamais remise en cause, ça se transforme en archaïsme et en un
rendement qui va décroissant AMHA. Je ne parle pas d'être sans cesse à
la pointe du progrès, mais de bien profiter des évolutions réelles.
Cela exige de se remettre en cause, et une vision à long terme, et
même dans le cadre d'une entreprise ça me semble la voie la plus
intelligente.

>>> Pourquoi cet amateurisme ?
>
>Ce n'est pas de l'amateurisme, mais du professionalisme, bien
>au contraire. Une entreprise n'est pas un labo de recherche, elle
>n'a pas le temps ni la vocation de tester le dernier machin qui vient
>de sortir et qui n'a pas encore fait ses preuves. Rentabilité toujours,
>les décideurs préfèrent bâtir sur du solide, ou ce qu'il croient être
>du solide. La recherche, les formations coûtent chères, le retour
>sur investissement doit être immédiat.

cf plus haut, la vision uniquement court terme ne me paraît pas une
solution viable.

>>Les gens font ce qu'ils savent faire, et s'y accrochent, même s'il existe
>>mieux ailleurs.
>
>Bien sûr, beaucoups de salariés aimeraient faire de la recherche,
>beaucoups aimeraient utiliser leur temps à quelque chose
>d'intéressant, beaucoups aimeraient nourrir leur famille grâce au
>produit de leur passion. Peu sautent le pas, et c'est compréhensible,
>il faut payer les traites de la baraque et de la voiture, les fournitures
>scolaires, les cadeaux de Noël...

Ce qui n'empêche pas de chercher à améliorer son quotidien de salarié
en utilisant au mieux les possibilités offertes et ne pas se cantonner
aux habitudes.
Ca vaut d'ailleurs à tous les niveaux : on innove pas sans se remettre
en cause.

Une belle démonstration du cynisme non?
Sans revenir sur le côté discutable de se sentir impuissant ou pire
indifférent face à tous les problèmes que vous avez cités, je pense
qu'il y a quelque chose que j'ai pas compris finalement : êtes-vous
satisfaits de l'omnipotence de la société de consommation?
J'espère que non. En tout cas moi non, et, peut-être naïvement, je
vois dans le développement des logiciels libres (qui obtiennent un
écho grandissant à l'heure actuelle) une possibilité de la création
d'un exemple fonctionnel d'une forme de coopération pour le bien de la
communauté qui me plaît beaucoup. Je ne suis pas assez naïf pour
penser que ça s'étendra demain à l'ensemble de la société, mais je
pense qu'il est très important que ce schéma de fonctionnement perdure
ne serait-ce que comme contrepoids au réflexe de consommation pur et
dur, au tout-propriétaire aussi. De plus l'informatique est très
largement diffusée dans notre société et la laisser toute entière aux
mains d'outils propriétaires menacerait selon moi l'information
qu'elle véhicule. Avec des softs libres il peut y avoir un contrôle.

Manu

[Jerome Kalifa]

"costaclt" <cost...@easynet.fr> writes:
[...]

>
> Il n'y a qu'à voir le côté pointilleux de la "querelle"
> GNUEmacs et XEmacs.

Il n'y a _pas_ de querelle, si ce n'est entre les developpeurs.
Simplement des differences (techniques, fonctionnement du
developpement) qui sont connues de maniere factuelle et objective par
les utilisateurs des deux logiciels, qui ont amene chacun a faire son
choix, mais qui ne portent pas a debat. Rien a voir avec les querelles
Emacs/Vi ou KDE/Gnome. La querelle entre developpeurs est d'ailleurs
l'unique raison du split, les utilisateurs ne demanderaient rien de
mieux qu'une convergence.
--
Jerome Kalifa
Centre de Mathematiques Appliquees, Ecole Polytechnique.
91128 Palaiseau Cedex, France. (33)169333982

[Michael Pujos]

<Snip tout le post>

Je comprends rien au langage de Nat :( ....suis je normal ?

[Herve Eychenne]

Nat Makarevitch <n...@linux-france.org> wrote:

>>> tu doutes de l'intérêt de développer N fois 'la mm chose'
>>> la 'meilleure' solution parmi un ensemble l'est souvent d'autant plus
>>> que l'ensemble compte d'éléments.

>> d'autres ensembles qui ne comportent encore que très peu d'éléments
>> (voire aucun), et qu'il serait peut-être bon de remplir au lieu
>> d'engraisser le cardinal d'autres déjà pas si mal pourvus.

> o, mais est-ce seulement possible ?

Tout est possible. A condition de trouver des gens suffisamment
convaincus pour le faire. Mais bon, c'est une phrase un peu creuse.

> constat : le développeur-type n'est intéressé que par certains projets et
> beaucoup ne souhaitent pas participer s'ils ne connaissent pas le thème
> sous-jacent. certains projets (système, graphisme ...) sont donc assez vite
> pourvus, mais le reste (gestion ... dommage, d'ailleurs, car sur ce front
> aussi on doit pouvoir coder de façon intéressante).

Cela vient du fait que les besoins sont ceux des développeurs, et pas
assez souvent ceux des utilisateurs (de logiciel libre).

> je pose que l'on souhaite satisfaire ts les besoins. une soluce possible :
> en appeler au mercenariat (exemple : le Free Software Bazaar). cela crée un
> modèle composite de softs libres réalisé selon des modalités apparentées à
> celles qui président aux oeuvres commerciales car des utilisateurs
> commandent et paient.

Je n'ai pas en têtes tous les détails de la chose, mais ce modèle me
semble bon.
Pour ceux qui souhaitent en savoir plus, par exemple:
http://visar.csustan.edu/bazaar/index.html

>>>> Il s'agit de trouver un moyen d'instaurer un sorte de couche de dialogue
>>>> suffisamment universelle

>>> ns 'parlions' de l'intérêt de multiples projets tendus vers un mm
>>> objectif, et voila que tu traites d'une extensibilité absolue.

>> Les deux thèmes sont peut-être disjoints, mais connexes.
>> Je ne vois pas en quoi le fait de trouver un dénominateur commun à
>> plusieurs logiciels empêcherait l'extension des possibilités d'un de
>> ces logiciels.

> n, au contraire ! mais cette découverte mm n'est souvent possible qu'après
> examen des fonctions assurées par le code. tu écris d'ailleurs « à
> plusieurs logiciels » plutôt que « à plusieurs cahiers des charges ».

Et pour cause, puisque les logiciels libres font très rarement l'objet
d'un tel cahier des charges.

> il faudrait donc parvenir à convaincre les développeurs de ces
> projets de l'intérêt d'une spécification des services proposés
> commune à plusieurs projets par ailleurs distincts et déjà
> 'matérialisés'. cela peut s'avérer d'autant plus difficile que ce
> processus exige souvent des modifications.

Bien évidemment.

> ou alors lancer un méta-projet visant à constituer une boîte noire
> garante de l'interopérabilité.

Cela me semble plus réaliste.

> boulot somme tte assez peu créatif, donc non gratifiant => peu de
> volontaires.

Je ne suis pas tout à fait de cet avis.
Certes, il y plus créatif sur le plan technique. Mais à mon sens, si
le modèle marche, cela pourrait être une petite révolution qui ferait
sans doute tache d'huile.

> pis : tt cela n'est pas envisageable lorsque les approches des
> concepteurs sont trop différentes.

Oui. Mais il s'il y a des approches vraiment différentes, il doit y avoir
les moyens de déterminer laquelle est la plus intéressante dans les cas
courants, comme je le disais déjà. Et on a alors la possibilité de
supporter l'un plutôt que l'autre.

>> Au pire, si une extension ne pouvait se faire sans briser le modèle,
>> rien n'empêche de le faire.

> les auteurs ne partageront probablement pas cet avis.

Ah ben ça, il faut parfois avoir le courage de sacrifier les auteurs sur
l'autel du progrès. ;-)
C'est le principe du logiciel libre qui veut ça: un logiciel qui n'évolue
plus (parce qu'il ne peut plus vraiment évoluer, ne serait qu'à cause de
problèmes structurels) sera inéluctablement remplacé par un concurrent
mieux conçu.

>> il ne faudrait pas que l'interface commune soit un carcan auquel nul ne
>> puisse se soustraire. C'est pour cela qu'il est nécessaire que le modèle
>> ne soit pas trop gros

> cette exigence limite son spectre d'application, et limite l'intérêt de la
> programmation 'exploratoire' (on code directement, sans trop se soucier de
> l'adéquation des structures de données et des algos) qui reste pourtant
> l'une des plus prometteuses lorsque l'on souhaite innover.

Je crois difficilement au hasard en informatique.

> le développeur peut au besoin gratter en vitesse des interfaces ad
> hoc vers d'autres codes, mais un cadre posé a priori peut
> restreindre son champ de vision.

Ca par contre, il est clair que l'on aurait sans doute beaucoup d'intérêt
à enfermer de jeunes prodiges n'ayant jamais vu d'ordinateur dans une
pièce pendant 5 ans. Il en sortirait sûrement des merveilles, que les
futurs informaticiens ne seront peut-être pas capables d'inventer, vu
le lourd passé culturel de l'informatique d'aujourd'hui.

>> L'expérience montre que les projets dont l'aspect trop ambitieux est
>> marqué dès le début n'attirent pas un grand nombre de développeurs

> o. sur le plan appliqué il me semble intéressant de constater que les
> langages qui n'intègrent pas de riche bibliothèque finissent par en receler
> une (C++ : je pense au parcourt (classes NIHCL et apparentées) -> STL) mais
> que les développeurs peinent à l'adopter (mauvais pli contracté ? adoption
> du langage motivée par son dépouillement même ?).

> les langages riches (par ex CL), eux, n'attirent pas les foules. est-ce
> parce que le mode de pensée de leurs concepteurs les conduit à les enrichir
> ainsi mais reste trop différent de celui des utilisateurs potentiels du
> langage ? ou à cause de cette richesse (coût lié à l'apprentissage) même ?

J'avoue que c'est un mystère. Dès que je trouve une bibliothèque qui
réalise une fonction dont j'aurais besoin, je l'utilise, pour peu qu'elle
soit assez portable (sous Unix, s'entend).

> or tt développeur sait bien qu'un outil trop dépouillé le condamne à sans
> cesse réinventer la roue.

Oui. Mais cela dérange moins de gens que je ne l'aurais cru.
On retrouve l'aspect ludique de l'informatique. Faire les choses par
soi-même est infiniment plus amusant et gratifiant que de prendre une
bibliothèque existante.
Si l'on doit réaliser une rotation de cube en 3D, on sera beaucoup plus
fier de soi si on a codé la chose en Xlib qu'en OpenGL.

> bref. tt le monde souhaite disposer d'une somme de composants réutilisables
> mais quasi personne ne veut la réaliser, et surtout peu se donnent les
> moyens de la maîtriser lorsqu'elle existe.

Exactement.

>> Les méta-objets sont intéressants à plus d'un titre.
>> Seulement, il faut bien admettre que le monde Linux est plus C que C++,

> :-))
> ah, cela me rappelle la tentative de C++isation du noyau !

Tout un poème. Et le commentaire de Torvalds à ce sujet:
"Certains ne partagent pas mon avis. Ignorez-les."

> seules des projets faisant table rase (par ex www.tunes.org) ou basés sur
> une application servant d'environnement pourraient déboucher, je le crains.

Et voilà, on retombe sur le concept de "reflectivité" et par extension sur
les méta-objets.

>>> tte action unificatrice peut condamner la saine émulation.

>> Mais en quoi le fait d'unifier un minimum les procédures d'intéraction
>> entre produits empêche-t-il les évolutions ?

> interaction => protocole => analyse visant à 'réduire', à décrire les
> entités manipulées et fonctions logiques assurées.

Pas à réduire: à mettre en commun ce qui peut l'être.

> si les logiciels existent déjà l'analyse privilégiera les choix des auteurs
> du soft le plus apprécié (par exemple : facile à embrasser) par celui qui
> la mène.

Si le logiciel est le plus utilisé parce qu'il est le mieux conçu, cela
est tout à fait valable. Dans le cas contraire (ça arrive, malheureusement),
il faudrait forker...

> les développeurs des autres logiciels ne pourront donc y adhérer
> qu'en rapprochant leurs oeuvres de cette 'référence'. en pratique, même ds
> un cas plutôt favorable, ils devront ajouter du code afin de proposer un
> mode d'accès à leur soft qui ressemblera étrangement à une 'boîte de
> compatibilité' de l'autre projet. une belle unification donne accès à tt,
> et beaucoup d'utilisateurs préféreront aborder ts ces outils via cette
> interface commune. tt cela confère au logiciel ainsi favorisé un statut
> proche de celui d'une implémentation de référence, y compris sur le
> terrain, sans lui ôter ses qualités propres. en pratique, à ce stade, les
> développeurs de ses 'concurrents' n'ont plus qu'à rejoindre ses auteurs ou
> renoncer.

Voilà.

> beaucoup de projets naissent d'un fork. il s'agit donc moins de rassembler
> des développeurs n'ayant jamais interagi que de renouer des contacts. juste
> avant le fork on constate que les conceptions des diverses personnes en
> présence divergent trop, surtout en matière de d'évaluation :
> 1/ - des notions d'« adéquation » et d'« élégance »,
> 2/ - des priorités (services à assurer ou n ds les plus brefs délais)

> 2/ est réductible par sondage des populations concernées (users), mais en
> pratique cela ne conduit à rien car les développeurs de libre agissent
> avant tt pour leur propre satisfaction, et ne st pas corvéables à merci. si
> ce n'était pas le cas ts fourgonneraient en ce moment mm sur des applis de
> gestion :-)

> 1/ est vraiment le noeud de l'affaire, et ns ne disposons à ma connaissance
> pas d'une méthode de quantification, d'une métrique efficace. lorsque Toto
> décide de s'atteler à une soluce bâtie sur/(grâce à) une ressource donnée
> (des profondeurs (noyau monolithique ou micro, SMP ou pas ...) jusqu'aux
> aspects politiques (utilisation d'une bibliothèque ou d'un langage plus ou
> moins 'imparfaitement libre' (Qt, Java ...)) nul ne peut exiger qu'il
> articule son développement autour d'une spécs relevant du plus petit commun
> dénominateur de l'ensemble des soluces possibles. il peut refuser de
> prendre le soin d'ajouter une interface conforme.

On ne peut rien exiger. Juste proposer.

> en pratique, à mon sens, tt cela implique que l'on ne peut espérer
> spécifier que les entités manipulées, seuls éléments communs non
> réducteurs.

Oui.

> le protocole d'interface commune doit donc découler d'une
> logique de 'transformations'. elle permettra d'exprimer au logiciel que
> l'on dispose d'un objet de nature N à convertir en objet N'. => l'interface
> pure : une seule méthode : 'type_cl_dest type_cl_src::transform()'. kewl
> (et voie ouverte pour les langages d'acteurs, sauf erreur).

> écueil : les codes existants ne se prêtent guère à cela, car on voit
> nettement se profiler, sous le règne de transform(), une architecture des
> codes obligatoirement posée sur des système multi-agents, du blackboard, et
> autres bidules du mm tonneau. de la recherche op à la sauce IA,
> quoi. gloups. les développeurs vont se faire rares :-)

Oui. Mais on n'est peut-être pas obligé d'aller aussi loin tout de suite !

>>>>>> fournir une bibliothèque de fonctions non interactives, au-dessus de
>>>>>> laquelle seraient bâties les interfaces

>>>>> cela pose des problèmes (pas uniquement d'ordre tech) à ma
>>>>> connaissance non résolus à ce jour, mais rien n'interdit de
>>>>> prospecter.

>>>> Quels problèmes "insolubles" ?

> « n résolus » n'est pas <=> « insolubles ».

> on ne peut pas espérer spécifier ttes les 'transformations' possibles, il
> faut donc laisser à chq code la possibilité d'explorer les autres
> dynamiquement. si un soft 'cherche' un traitement par lequel l'un de ses
> objets de type T sera transformé en objet de type N il doit être à même de
> 'décrire' ce qu'est ce N !

Oui, c'est assez classique.

> adieu les liaisons statiques, on se retrouve en pleine soupe d'objets. que
> faire, en runtime, lorsqu'un service (de transformation, ici) nécessaire
> n'est pas dispo (pb que posent aussi des langages de la famille C, par
> exemple Objective C) ? doit-on confier le routage des requêtes à une
> autorité centrale ou bien laisser ts les codes interagir librement ? que
> faire en cas de conflit (plus d'un service dispo) ? à tout changement
> d'état perceptible de l'extérieur tt soft devra associer une classe, or
> certaines transitions sont difficiles à formaliser ainsi (surtout si du
> locking ou la notion de 'temps écoulé' s'en mêlent) ... des tonnes de pbs !

Tous les problèmes que posent les méta-objets distribués.
Pas simple, en effet.

>>> en tt premier lieu le fait que les outils (langages, surtout) les plus en
>>> vogue ne permettent pas vraiment aux logiciels de s'« introspecter ».

>> J'ai du mal à cerner la chose. ;-)

> grâce à elle un soft pourrait s'enquérir des services offerts par d'autres
> codes.

Ah, tu voulais dire de "s'interspecter", alors ! ;-)

>> le logiciel libre, s'il devient un acteur principal du marché mondial
>> comme il semble en prendre le chemin, est-il capable de générer des
>> technologies puissantes qui tireraient la communauté toute entière vers

>> le haut ?

> je le crois, car :
> - l'émulation joue à plein,
> - l'exposition des réalisation (sources) permet à tt un chacun de
> progresser à son rythme

Oui, mais des projets moins bien conçus, rencontreront plus de succès
que d'autres, mieux ficelés, mais plus compliqués. Le premier, profitant
d'un nombre de développeurs plus important, musellera le suivant.
Tout cela me fait un peu penser à KDE/Gnome. ;-)

>> n'est-il pas quelque part condamné à demeurer techniquement limité pour
>> être accessible à tous, et assurer ainsi son devenir ?

> à mon sens n. car le LL n'est pas homogène. ni par les gabarits, ni par les
> orientations, ni par les langages (...). le source du 'ls' des fileutils
> est libre, de mm que celui d'Emacs. hacker l'un d'eux est cependant un poil
> plus ardu.

Et pourtant, même le code des fileutils est très bien fichu. ;-)

>>> quand on va jusqu'à décrire aussi précisément que possible le 'comment',
>>> au lieu de se contenter du 'pourquoi', on bride a priori les
>>> développeurs.

>> Non, pas aussi précisemment que possible. Il faut plutôt fournir un
>> cadre

> peux-tu mieux le circonscrire ? qu'est-ce qui doit être spécifié ?

Question difficile ! Cela dépend du type d'application que l'on désirerait
"unifier". On peut définir la liste des couches/composantes, ainsi qu'un
protocole leur permettant de communiquer entre elles.
Et même écrire une bibliothèque. A chacun d'écrire les dites composantes
comme il l'entend.

[devivie . enserb . u-bordeaux . fr]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> wrote:
|Nat Makarevitch <n...@linux-france.org> wrote:

|> :-))
|> ah, cela me rappelle la tentative de C++isation du noyau !

|Tout un poème. Et le commentaire de Torvalds à ce sujet:
|"Certains ne partagent pas mon avis. Ignorez-les."

Le C++ permet sans doute de mieux aborder l'aspect "design" (ce
qui dans le cas d'un OS, est passionnant). J'avais chercher des
infos à ce sujet mais les arguments que l'on trouve dans les
HOWTO sont basés sur la performance et un manque de maturité
du compilo c++ (argument qui serait sans doute à reconsiderer).

Récement je suis tombé sur un post beaucoup plus pertinent en
faveur du C. Le voici:

_______________________________________
From: emmanue...@skynet.be
Newsgroups: fr.comp.lang.c++,fr.com.lang.c
Subject: Re: Gtk+ : pourquoi en C et pas en C++ ?
Date: Wed, 14 Apr 1999 17:54:56 GMT

Re-Rebonjour,
l'argument le plus concret et le plus solide en faveur du choix du C
pour une biblio du type de Gtk+ m'a été donné aujourd'hui (via la
mailing-list gtk-list) :
le fait de réimplémenter la gestion objet de zéro en C donne une
extrême souplesse ("on peut vraiment intervenir n'importe où et de
façon dynamique", concrètement je ne visualise pas les détails, mais
ça se comprend en gros :), ce qui permet de l'interfacer avec
n'importe quel langage. En C++ on aurait pas autant de contrôle de la
gestion des objets puisqu'elle est intégrée et transparente.
Un autre argument, plus technique disons, est que l'implémentation
objet est différente pour chaque compilateur (je suppose qu'il s'agit
de comment le compilo gère l'héritage, le polymorphisme), et le
"codage" (mangling) des noms de fonction aussi, ce qui obligerait tout
le monde à utiliser recompiler la lib avec son propre compilateur et à
savoir comment lui fait pour gérer tout ça : pas terrible pour la
portabilité :) (ceci est d'ailleurs valable pour l'écriture d'une lib
en C++ quelconque).
Manu
_______________________________________

PS: il y a t'il encore un projet de c++isation du noyeau ?

[Nat Makarevitch]

Michael Pujos writes:

> <Snip tout le post>
> Je comprends rien au langage de Nat :( ....suis je normal ?

prévisible :
> Organization: Quakers on-line

(pas pu résister ...)

plus sérieusement : ce débat est un peu hors-thème (n spécifique à Linux),
et parfois techniqueux/jargonisant, aussi. pas de panique. à traiter comme
un 'écran bleu' : on rebooter et on oublie.

[Nat Makarevitch]

Herve Eychenne writes:

> ce modèle me semble bon.
> Pour ceux qui souhaitent en savoir plus, par exemple:

http://www.linux-france.org/prj/fsb/

[ plusieurs prj aux objectifs semblables ]

>> lancer un méta-projet visant à constituer une boîte noire garante de
>> l'interopérabilité.

> si le modèle marche, cela pourrait être une petite révolution qui ferait

> sans doute tache d'huile.

il faut essayer. cela m'intéresse. une idée de prj ?

> Mais il s'il y a des approches vraiment différentes, il doit y avoir les
> moyens de déterminer laquelle est la plus intéressante dans les cas
> courants

quels critères doit-on prendre en considération ?

>>> Au pire, si une extension ne pouvait se faire sans briser le modèle,
>>> rien n'empêche de le faire.

>> les auteurs ne partageront probablement pas cet avis.

> C'est le principe du logiciel libre qui veut ça: un logiciel qui n'évolue
> plus

> sera inéluctablement remplacé par un concurrent mieux conçu.

tt à fait d'accord, mais ns traitions de projets simultanément actifs et
disposant chacun d'utilisateurs convaincus. le cas du prj en perdition se
règle en effet seul.

> Je crois difficilement au hasard en informatique.

il sévit (ou accorde) pourtant partout, y compris en info.

>> le développeur

>> un cadre posé a priori peut restreindre son champ de vision.

> Ca par contre, il est clair que l'on aurait sans doute beaucoup d'intérêt
> à enfermer de jeunes prodiges n'ayant jamais vu d'ordinateur dans une
> pièce pendant 5 ans

idée intéressante, mais le recrutement des volontaires posera qq pbs

>> or tt développeur sait bien qu'un outil trop dépouillé le condamne à sans
>> cesse réinventer la roue.

> On retrouve l'aspect ludique de l'informatique. Faire les choses par

> soi-même est infiniment plus amusant et gratifiant

un résultat convaincant l'est à mon sens tt autant, mais cela relève des
mentalités ('utilitarisme' ?) que nulle méthode ou exposé théorique ne peut
modifier.

> on retombe sur le concept de "reflectivité" et par extension sur les
> méta-objets.

incontournables, mais qui n'infusent guère ds la population. peut-être
qu'un langage simple et élégant ...

>>>> tte action unificatrice peut condamner la saine émulation.

>>> en quoi le fait d'unifier un minimum les procédures d'intéraction entre

>>> produits empêche-t-il les évolutions ?

>> interaction => protocole => analyse visant à 'réduire', à décrire les
>> entités manipulées et fonctions logiques assurées.

> Pas à réduire: à mettre en commun ce qui peut l'être.

donc 'réduire' (au sens qu'à ce terme en chimie mais aussi ds la vie
courante), car cette 'factorisation' produira un ensemble moins étoffé que
celui qu'offre l'un des logiciels.

>>>> en tt premier lieu le fait que les outils (langages, surtout) les plus
>>>> en vogue ne permettent pas vraiment aux logiciels de s'« introspecter
>>>> ».

>> s'enquérir des services offerts par d'autres codes.

> Ah, tu voulais dire de "s'interspecter", alors ! ;-)

o, j'y pensais en tant qu'ensemble (composite mais
cohérent). 'interspecter' est plus explicite.

> Le premier, profitant d'un nombre de développeurs plus important,
> musellera le suivant.
> Tout cela me fait un peu penser à KDE/Gnome. ;-)

o !

>>> Il faut plutôt fournir un cadre

>> peux-tu mieux le circonscrire ?

> Cela dépend du type d'application que l'on désirerait "unifier".

c'est là que le bât blesse, peut-être. une méthode applicable à ts les cas
manque à l'appel.

> On peut définir la liste des couches/composantes, ainsi qu'un protocole
> leur permettant de communiquer entre elles. Et même écrire une
> bibliothèque. A chacun d'écrire les dites composantes comme il l'entend.

approche fort courante ds divers domaines, y compris fort proches du
nôtre. je pense par exemple aux réseaux (plus particulièrement aux NSAP,
sur le plan fonctionnel). serait-il possible de s'en inspirer afin de
définir des formalismes (services rendus et messages associés) ? qq'1 a
probablement déjà planché (?)

[Nat Makarevitch]

devivie writes:

>>> ah, cela me rappelle la tentative de C++isation du noyau !

> Le C++ permet sans doute de mieux aborder l'aspect "design" (ce qui dans
> le cas d'un OS, est passionnant)

o

> le fait de réimplémenter la gestion objet de zéro en C donne une
> extrême souplesse
> ("on peut vraiment intervenir n'importe où et de façon dynamique",

c'est exact mais des tonnes d'autres langages (en tête : CL) offrent divers
moyens le modèle sous-jacent. réaliser cela en C => réinventer la roue, et
se priver des ressources élégantes de ces langages (souvent par flemme de
s'y atteler :-) )

> ce qui permet de l'interfacer avec n'importe quel langage

FFI (Foreign Function Interface)

> En C++ on aurait pas autant de contrôle de la gestion des objets
> puisqu'elle est intégrée et transparente.

o, mais pb résolu par d'autres langages

> l'implémentation objet est différente pour chaque compilateur

mais cela doit par définition rester transparent

> et le "codage" (mangling) des noms de fonction aussi

il est sauf erreur délibéré afin d'assurer la surcharge (le 'polymorphisme'
(dans l'acception C++ du terme)), la résolution en cas de méthodes
virtuelles (...)

> PS: il y a t'il encore un projet de c++isation du noyeau ?

je n'en ai pas entendu parler.

[Herve Eychenne]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:

>>> lancer un méta-projet visant à constituer une boîte noire garante de
>>> l'interopérabilité.

>> si le modèle marche, cela pourrait être une petite révolution qui ferait

>> sans doute tache d'huile.

> il faut essayer. cela m'intéresse. une idée de prj ?

Pourquoi pas. Mais j'ai déjà tellement de projets en tête !
Une vie entière ne suffirait sans doute pas à les réaliser... :-(

>> Mais il s'il y a des approches vraiment différentes, il doit y avoir les
>> moyens de déterminer laquelle est la plus intéressante dans les cas

>> courants

> quels critères doit-on prendre en considération ?

Difficile à dire... Quand je vois une belle chose, je sais la reconnaître.
Mais pas toujours expliquer ce qui me semble beau. Banal, en somme.

>>>> Au pire, si une extension ne pouvait se faire sans briser le modèle,
>>>> rien n'empêche de le faire.

>>> les auteurs ne partageront probablement pas cet avis.

>> C'est le principe du logiciel libre qui veut ça: un logiciel qui n'évolue
>> plus

>> sera inéluctablement remplacé par un concurrent mieux conçu.

> tt à fait d'accord, mais ns traitions de projets simultanément actifs et

> disposant chacun d'utilisateurs convaincus. le cas du prj en perdition se
> règle en effet seul.

Bon, alors pour un projet actif, si le(s) développeur(s) ne veulent pas
entendre raison, le fork semble inévitable.
Mais on peut espérer que les utilisateurs choisiront le nouveau projet,
puisqu'il est bon ;-), et qu'on fois la "bataille" remportée, les
développeurs de l'appli initiale (avant fork) se ralieront à la cause
du projet fils. Mais je radote.

>> Je crois difficilement au hasard en informatique.

> il sévit (ou accorde) pourtant partout, y compris en info.

Je ne vois pas vraiment en quoi...

>>> le développeur

>>> un cadre posé a priori peut restreindre son champ de vision.

>> Ca par contre, il est clair que l'on aurait sans doute beaucoup d'intérêt
>> à enfermer de jeunes prodiges n'ayant jamais vu d'ordinateur dans une

>> pièce pendant 5 ans

> idée intéressante, mais le recrutement des volontaires posera qq pbs

C'est sûr. ;-)
Remarque, un vrai informaticien serait sans doute capable de s'enfermer
de la sorte pendant 5 ans... ;-)

>>> interaction => protocole => analyse visant à 'réduire', à décrire les
>>> entités manipulées et fonctions logiques assurées.

>> Pas à réduire: à mettre en commun ce qui peut l'être.

> donc 'réduire' (au sens qu'à ce terme en chimie mais aussi ds la vie

> courante), car cette 'factorisation' produira un ensemble moins étoffé que
> celui qu'offre l'un des logiciels.

Oui, mais ce logiciel plus complet pourra toujours utiliser ses
fonctionnalités plus poussées.
Une autre méthode consiste au contraire à placer dans la bibliothèque
les fonctions relatives à l'implémentation la plus avancée, un peu
comme le VFS qui est quasiment une copie de l'interface de ext2.
Bien sûr, certaines fonctions ne seraient pas disponibles sur les
applications plus limitées. Mais cela ne pourrait que le pousser à les
développer.
En fait, je penche plutôt pour la seconde méthode !

>>>> Il faut plutôt fournir un cadre

>>> peux-tu mieux le circonscrire ?

>> Cela dépend du type d'application que l'on désirerait "unifier".

> c'est là que le bât blesse, peut-être. une méthode applicable à ts les cas
> manque à l'appel.

Oui, je sais bien. Mais à force de viser l'universalité, on n'atteint pas
le but principal: fournir quelque chose d'utilisable par un être humain. ;-)
Peut-être la stratégie du "grignotage" est-elle plus conforme au modèle
de développement libre.
En tout cas, pour un tel projet, je ne me sens pas capable de viser trop
haut.

>> On peut définir la liste des couches/composantes, ainsi qu'un protocole
>> leur permettant de communiquer entre elles. Et même écrire une
>> bibliothèque. A chacun d'écrire les dites composantes comme il l'entend.

> approche fort courante ds divers domaines, y compris fort proches du

> nôtre. je pense par exemple aux réseaux (plus particulièrement aux NSAP,
> sur le plan fonctionnel). serait-il possible de s'en inspirer afin de
> définir des formalismes (services rendus et messages associés) ? qq'1 a
> probablement déjà planché (?)

Autant mettre toutes les applis à la mode Corba... C'est ce qui s'est
amorçé avec Gnome, d'ailleurs. Mais cela n'est parti pour concerner que des
applications 100% graphiques, alors qu'il faudrait l'étendre à tous les
niveaux, à ce compte-là.
Bon, voici quelques idées relatives à ce que je considère être la bonne
marche à suivre pour le développement d'une application.

Dans ce qui suit, je désignerai par interface interactive une "surcouche"
permettant à l'utilisateur d'utiliser l'application en intervenant dans
son déroulement. A noter qu'une telle interface peut être réalisée en
mode texte ou sous X.

Programmation:
- L'application doit être disponible sous un maximum d'architecture
(de type Unix, ça va de soi). Pour cela, autoconf et consorts sont
d'une grande utilité.
- L'application doit être internationalisable. gettext fournit un bon
moyen de réaliser cela.
- Le programmeur doit se concentrer autant que possible sur ce qu'il sait
faire de mieux, et qu'assez peu d'autres peuvent faire à sa place:
programmer.

Configuration:
- Toute modification de la configuration doit être formalisée dans un
fichier enregistrable.
- Ce fichier (assez concis, mais pas trop) doit être présenté sous forme
lisible (texte) et pouvoir être modifié au moyen de n'importe quel éditeur.
- En utilitaire présentant le contenu de ce fichier dans une langue
intelligible (pourquoi pas en langue écrite) est le bienvenu.
- Toute intervention se faisant par interface interactive interposée ou
par une méthode non-interactive doit faire l'objet d'une conversion en
une ou plusieurs lignes de configuration, avec la possibilité de visualiser
immédiatement les changements de ces lignes, si l'utilisateur le souhaite.

Ergonomie:
- Par extension, le fonctionnement doit être assez transparent par défaut,
mais aussi détaillé que possible pour celui qui souhaite savoir ce qui est
effectué.
- A chacun de choisir son niveau d'abstraction.
Pourquoi ne pas envisager plusieurs niveaux de "difficulté" (un peu à la
manière des jeux ;-), afin de permettre à l'utilisateur de progresser
graduellement sans se laisser embrouiller par trop de fonctionnalités ?

Interfaces interactives:
- Il est préférable de commencer le développement par une commande shell
non-interactive. Puis, développer une interface interactive sous shell,
ce qui permet aux gens ne disposant pas de X (vieux matériel ou accès
distant), ou désirant une efficacité maximale de bénéficier d'une interface
aussi conviviale et rapide que possible.
Puis, l'application doit être implémentée sous X-Window, en gardant à
l'esprit une approche très modulaire.
- Si l'on considère une commande shell et son interface interactive
correspondante, soit l'interface s'appuie sur la commande shell, ce qui
n'est pas très puissant, soit (mieux !) l'un et l'autre s'appuient
sur une bibliothèque regroupant un maximum de fonctions communes.
Cette bibliothèque pourra regrouper des fonctions communes d'aussi haut
niveau que possible, sans toutefois omettre les fonctions élémentaires.
- Les interfaces interactives doivent permettre toutes les opérations qu'une
commande shell correspondante permettrait de réaliser, ou du moins un
maximum, puisque l'interface est souvent réductrice. Au besoin, s'il n'est
pas possible de faire autrement, celle-ci devra permettre de rentrer
des opérations au clavier (exemple typique: saisie d'expressions
régulières).
- Les fonctions standard de l'application interactive doivent être faciles
à identifier et à utiliser. Les fonctions plus complexes doivent faire
l'objet d'une partie séparée dans chacun rubrique (faire l'objet d'un
onglet séparé sous X, par exemple). Ces parties seraient identifiées
comme étant plus délicates à utiliser, et clairement identifiables, afin
de ne pas perturber l'utilisateur novice.
Malgré tout, elles doivent être facilement accessibles, afin de ne pas
pénaliser l'utilisateur averti.
- Dans le cas d'une application X, chaque partie de l'interface doit
faire l'objet d'un système d'aide plus ou moins détaillée et approfondie
suivant le niveau d'utilisation, accessible de façon uniforme, ou
apparaîssant automatiquement en mode "novice".
- Comme précisé plus haut, tous les niveaux d'applications doivent être
implémentés.
Si une commande shell doit absolument posséder un équivalent graphique
pour ceux qui le désirent, de même, un maximum d'opérations effectuées
par une application interactive doivent être réalisables de manière
non-interactive, quand cela est possible.
Dans ce dernier cas, l'application interactive doit bien sûr fournir à
la demande de l'utilisateur la ligne de commande effectuant ces
opérations.
- Ainsi, il doit être possible d'agir dans l'application graphique (en train
de s'exécuter) par le biais de commandes non-interactives, utilisant
un protocole bien défini, implémenté sous forme de bibliothèque, par
exemple.
- Une séquence d'utilisation interactive doit pouvoir être sauvée dans un
fichier écrit dans un langage de type batch, et pouvant être retravaillé.
- A contrario, ceci permettrait de pouvoir réaliser par script une session
interactive graphique complète, par l'intermédiaire de ce langage. L'une
des applications serait bien évidemment l'écriture des séquences de
démonstration d'utilisation, outil d'apprentissage (voire de télé-
maintenance) incomparable.
- Les dialogues entre différentes composantes d'une même application sont
intéressants, mais ils ne suffisent pas: le dialogue inter-applications
doit être prévu. Il faut donc définir avec soin ce qui est importable et
exportable, et la manière de réaliser ces échanges.
- L'état d'une application interactive doit pouvoir être sauvegardé autant
que possible, afin de permettre à l'utilisateur de reprendre sa session
ultérieurement à l'endroit où il l'avait laissée, et ce même après un
reboot.
- Dans le cas idéal (difficile, et même parfois impossible à réaliser),
une commande X ainsi interrompue doit pouvoir être continuée en mode texte,
et réciproquement, ce qui suppose un format de sauvegarde suffisamment
général pour s'adapter aux 2 modes.
- Par extension, il serait envisageable de transférer une session active
(ou pas) sur une autre machine.

Tout cela est évidemment bien ambitieux. A tel point que je ne connaisse
pas une application qui réalise la moitié du quart de ses spécifications,
même tous ces points sont déjà sûrement réalisés séparément par au moins
une application existante.

Enfin, l'une des applications que je suis en train d'écrire est bien
partie pour les concilier tous... mais elle est encore loin d'être
terminée. ;-)

RV

P.S.: bon, si je voulais faire court, c'est encore raté. Désolé...

[devivie . enserb . u-bordeaux . fr]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:

|> le fait de réimplémenter la gestion objet de zéro en C donne une
|> extrême souplesse
|> ("on peut vraiment intervenir n'importe où et de façon dynamique",

|c'est exact mais des tonnes d'autres langages (en tête : CL) offrent divers
|moyens le modèle sous-jacent. réaliser cela en C => réinventer la roue, et
|se priver des ressources élégantes de ces langages (souvent par flemme de
|s'y atteler :-) )

Oui ! Et c'est bien dommage de se priver des possibilités qu'offrent les
langages de nouvelles générations. La flemme est un facteur limitant mais
il y a aussi l'inertie d'un système déjà en place, les facultés de
conceptions sont plus poussés pour certain langage et bien sûr les
spécificités de chaque langage. Là encore, des solutions mixtes sont
peut-être envisageables. Je ne connais pas CL, mais je suppose qu'il a
des avantages notables ? Est-il mieux que ML ? (je suis un fana de ML :-) )

|> En C++ on aurait pas autant de contrôle de la gestion des objets
|> puisqu'elle est intégrée et transparente.

|o, mais pb résolu par d'autres langages

C++ est un langage OO parmis d'autres; ce n'est certainement pas le mieux
pour envisager une reconception du noyeau mais il a l'avantage d'être une
extension du C (en considérant l'existant).

|> l'implémentation objet est différente pour chaque compilateur

|mais cela doit par définition rester transparent

Oui ! D'ailleur un des points clef des compilos est le respect de la
sémantique. Dans les langages bien spécifiés, il existe des suites de tests
permettant de certifier le compilo. Il existe aussi d'autres type de
certifications portant plutôt sur le code généré ( généralement utilisé
pour produire du code RT. ) et c'est dans ce domaine que le choix de C
est judicieux car les compilateurs sont très performants.

|> PS: il y a t'il encore un projet de c++isation du noyeau ?

|je n'en ai pas entendu parler.

Ce serait pourtant sympa d'avoir une belle conception OO du noyeau avec un
langage permettant d'exprimer aussi le parallélisme ! Je suis sûr qu'il y
aurait pas mal de partants sur un tel projet ;)

[Herve Eychenne]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:

>>> lancer un méta-projet visant à constituer une boîte noire garante de
>>> l'interopérabilité.

>> si le modèle marche, cela pourrait être une petite révolution qui ferait

>> sans doute tache d'huile.

> il faut essayer. cela m'intéresse. une idée de prj ?

Pourquoi pas. Mais j'ai déjà tellement de projets en tête !
Une vie entière ne suffirait sans doute pas à les réaliser... :-(

>> Mais il s'il y a des approches vraiment différentes, il doit y avoir les

>> moyens de déterminer laquelle est la plus intéressante dans les cas

>> courants

> quels critères doit-on prendre en considération ?

Difficile à dire... Quand je vois une belle chose, je sais la reconnaître.
Mais pas toujours expliquer ce qui me semble beau. Banal, en somme.

>>>> Au pire, si une extension ne pouvait se faire sans briser le modèle,

>>>> rien n'empêche de le faire.

>>> les auteurs ne partageront probablement pas cet avis.

>> C'est le principe du logiciel libre qui veut ça: un logiciel qui n'évolue
>> plus

>> sera inéluctablement remplacé par un concurrent mieux conçu.

> tt à fait d'accord, mais ns traitions de projets simultanément actifs et

> disposant chacun d'utilisateurs convaincus. le cas du prj en perdition se
> règle en effet seul.

Bon, alors pour un projet actif, si le(s) développeur(s) ne veulent pas
entendre raison, le fork semble inévitable.
Mais on peut espérer que les utilisateurs choisiront le nouveau projet,
puisqu'il est bon ;-), et qu'on fois la "bataille" remportée, les
développeurs de l'appli initiale (avant fork) se ralieront à la cause
du projet fils. Mais je radote.

>> Je crois difficilement au hasard en informatique.

> il sévit (ou accorde) pourtant partout, y compris en info.

Je ne vois pas vraiment en quoi...

>>> le développeur

>>> un cadre posé a priori peut restreindre son champ de vision.

>> Ca par contre, il est clair que l'on aurait sans doute beaucoup d'intérêt
>> à enfermer de jeunes prodiges n'ayant jamais vu d'ordinateur dans une

>> pièce pendant 5 ans

> idée intéressante, mais le recrutement des volontaires posera qq pbs

C'est sûr. ;-)
Remarque, un vrai informaticien serait sans doute capable de s'enfermer
de la sorte pendant 5 ans... ;-)

>>> interaction => protocole => analyse visant à 'réduire', à décrire les

>>> entités manipulées et fonctions logiques assurées.

>> Pas à réduire: à mettre en commun ce qui peut l'être.

> donc 'réduire' (au sens qu'à ce terme en chimie mais aussi ds la vie

> courante), car cette 'factorisation' produira un ensemble moins étoffé que
> celui qu'offre l'un des logiciels.

Oui, mais ce logiciel plus complet pourra toujours utiliser ses
fonctionnalités plus poussées.
Une autre méthode consiste au contraire à placer dans la bibliothèque
les fonctions relatives à l'implémentation la plus avancée, un peu
comme le VFS qui est quasiment une copie de l'interface de ext2.
Bien sûr, certaines fonctions ne seraient pas disponibles sur les
applications plus limitées. Mais cela ne pourrait que le pousser à les
développer.
En fait, je penche plutôt pour la seconde méthode !

>>>> Il faut plutôt fournir un cadre

>>> peux-tu mieux le circonscrire ?

>> Cela dépend du type d'application que l'on désirerait "unifier".

> c'est là que le bât blesse, peut-être. une méthode applicable à ts les cas
> manque à l'appel.

Oui, je sais bien. Mais à force de viser l'universalité, on n'atteint pas
le but principal: fournir quelque chose d'utilisable par un être humain. ;-)
Peut-être la stratégie du "grignotage" est-elle plus conforme au modèle
de développement libre.
En tout cas, pour un tel projet, je ne me sens pas capable de viser trop
haut.

>> On peut définir la liste des couches/composantes, ainsi qu'un protocole

>> leur permettant de communiquer entre elles. Et même écrire une
>> bibliothèque. A chacun d'écrire les dites composantes comme il l'entend.

> approche fort courante ds divers domaines, y compris fort proches du

pas une application qui réalise la moitié du quart de ces spécifications,

même tous ces points sont déjà sûrement réalisés séparément par au moins
une application existante.

Enfin, l'une des applications que je suis en train d'écrire est bien
partie pour les concilier tous... mais elle est encore loin d'être
terminée. ;-)

RV

P.S.: bon, si je voulais faire court, c'est encore raté. Désolé...

--

[Herve Eychenne]

devivie @ info . enserb . u-bordeaux . fr wrote:

> |> PS: il y a t'il encore un projet de c++isation du noyeau ?

> |je n'en ai pas entendu parler.

> Ce serait pourtant sympa d'avoir une belle conception OO du noyeau avec un
> langage permettant d'exprimer aussi le parallélisme ! Je suis sûr qu'il y
> aurait pas mal de partants sur un tel projet ;)

On ne va pas relancer le débat, mais un noyau se doit d'êre le plus petit et
rapide possible. Jusqu'à preuve du contraire, le C l'emporte de ces deux
points de vue. Je ne suis pas un anti-C++ primaire, mais pour moi, la
question ne se pose pas.

[Herve Eychenne]

Jerome Kalifa <Jerome...@polytechnique.fr> wrote:

>> - Ce fichier (assez concis, mais pas trop) doit être présenté sous forme
>> lisible (texte) et pouvoir être modifié au moyen de n'importe quel éditeur.

> [...]

> Je ne suis pas convaincu par ce point la. Je pense que l'on doit
> pouvoir faire des choses tres bien par des bases de registres
> binaires, si l'on s'y prend correctement.

Sans doute...

> C'est un sujet de debat permanent a propos de Berlin, qui a choisi
> cette voie. Les performances et la securite font partie de leurs
> principales motivations.

Pour ce qui est des performances, je veux bien croire que le format
binaire est plus adapté. Mais il me semble que les disques sont
suffisamment rapides pour "perdre" quelques millisecondes à lire un
fichier de configuration, en regard de la lisibilité et de la souplesse
que cela apporte.
Ne pas oublier qu'un fichier de configuration commenté et envoyé par
le réseau est sans commune mesure avec un fichier binaire complètement
inintelligible.
Quand à la sécurité, si j'ai bien compris les motivations des développeurs
de Berlin, le fait de rendre une information lisible, mais intelligible
n'a jamais constitué une protection efficace.
D'autre part, les fichiers de configuration sont rarement destinés à
être cryptés...

RV

[Michael Pujos]

On 9 May 1999 22:20:01 +0200, Eric Jacoboni <ja...@titine.fr.eu.org>
wrote:

>blon...@news.ens.fr (Sebastien Blondeel) writes:
>
>> C'est la thèse de l'octroi : il faut avoir fait quinze ans d'études pour
>> commencer à comprendre ce qu'il raconte.
>
>J'avais pensé écrire un Nat-HOWTO mais, de toutes façons, personne ne
>lis les HOWTOs...

Il suffit d'ecrire un HOWTO-HOWTO , pour dire aux gens de lire les
HOWTO.

:)

[Jerome Kalifa]

devivie @ info . enserb . u-bordeaux . fr writes:
[...]

>
> Je ne connais pas CL, mais je suppose qu'il a
> des avantages notables ? Est-il mieux que ML ? (je suis un fana de ML :-) )
>

A moins que je n'ai rien compris a ce que voulait dire Nat, ce que Nat
designe par CL, je pense que tu dois connaitre puisque c'est tout
simplement Common Lisp. Donc, non, il n'est pas mieux notamment que
Objective Caml, loin de la. Mais il est mieux accepte car plus ancien,
et Americain de surcroit. D'ailleurs, AMHA, CLOS n'est franchement pas
une reussite.

[...]

>
> C++ est un langage OO parmis d'autres;

Faut le dire vite :)

[Jerome Kalifa]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> writes:
[...]

>
> - Ce fichier (assez concis, mais pas trop) doit être présenté sous forme
> lisible (texte) et pouvoir être modifié au moyen de n'importe quel éditeur.

[...]

Je ne suis pas convaincu par ce point la. Je pense que l'on doit
pouvoir faire des choses tres bien par des bases de registres

binaires, si l'on s'y prend correctement. C'est un sujet de debat

permanent a propos de Berlin, qui a choisi cette voie. Les
performances et la securite font partie de leurs principales
motivations.

[Nat Makarevitch]

devivie writes:

> c'est bien dommage de se priver des possibilités qu'offrent les langages
> de nouvelles générations

de nombreux langages contemporains n'offrent que peu de 'prédictabilité'.
diverses actions se déroulent en sous-main (par exemple le gc), ce qui rend
la programmation système (timings ...) parfois délicate.

> Je ne connais pas CL, mais je suppose qu'il a des avantages notables ?

et comment ! en particulier une souplesse dingue : tu peux par exemple
exprimer le pb dans sa propre 'langue'.

> Est-il mieux que ML ?

je connais mal ML. ils sont en effet plutôt différents

>>> projet de c++isation du noyeau ?

> Ce serait pourtant sympa d'avoir une belle conception OO du noyeau

pourquoi ? tu devrais argumenter ! :-)

--
Nat

[Nat Makarevitch]

Jerome Kalifa writes:

>> - Ce fichier

>> doit être présenté sous forme lisible (texte)

> Je ne suis pas convaincu par ce point la. Je pense que l'on doit pouvoir

> faire des choses tres bien par des bases de registres binaires

les laisser en txt a beaucoup d'avantages : engendrement/traitement
automatique facilité et surtout mode dégradé plus facile à gérer

pourquoi ne pas claquer un 'tokeniseur' capable d'agir automatiquement si
nécessaire ?
à la Emacs : .el/.elc, mais avec un 'make' intégré

[Marc SCHAEFER]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:
> les laisser en txt a beaucoup d'avantages : engendrement/traitement
> automatique facilité et surtout mode dégradé plus facile à gérer

Aussi, un mode texte peut rendre les ``diff'' et les ``patch'' très
faciles. Par contre, pour faire l'équivalent en binaire, il faut
absolument connaître la structure interne. Dans le cas contraire,
la différence ne sera pas optimale.

[Herve Eychenne]

Jerome Kalifa <Jerome...@polytechnique.fr> wrote:

>> - Ce fichier (assez concis, mais pas trop) doit être présenté sous forme
>> lisible (texte) et pouvoir être modifié au moyen de n'importe quel éditeur.

> [...]

> Je ne suis pas convaincu par ce point la. Je pense que l'on doit
> pouvoir faire des choses tres bien par des bases de registres

> binaires, si l'on s'y prend correctement.

Sans doute...

> C'est un sujet de debat permanent a propos de Berlin, qui a choisi
> cette voie. Les performances et la securite font partie de leurs
> principales motivations.

Pour ce qui est des performances, je veux bien croire que le format

binaire est plus adapté. Mais il me semble que les disques sont
suffisamment rapides pour "perdre" quelques millisecondes à lire un
fichier de configuration, en regard de la lisibilité et de la souplesse
que cela apporte.
Ne pas oublier qu'un fichier de configuration commenté et envoyé par
le réseau est sans commune mesure avec un fichier binaire complètement
inintelligible.
Quand à la sécurité, si j'ai bien compris les motivations des développeurs

de Berlin, le fait de rendre une information lisible, mais inintelligible

n'a jamais constitué une protection efficace.
D'autre part, les fichiers de configuration sont rarement destinés à
être cryptés...

RV

--

[Sebastien Blondeel]

According to Michael Pujos <mpu...@mail.dotcom.fr>:

> Je comprends rien au langage de Nat :( ....suis je normal ?

Tu es logé à la même enseigne que nous tous ici, mais plus honnête que
ceux qui font semblant de comprendre en répondant.

[Eric Jacoboni]

blon...@news.ens.fr (Sebastien Blondeel) writes:

> C'est la thèse de l'octroi : il faut avoir fait quinze ans d'études pour
> commencer à comprendre ce qu'il raconte.

J'avais pensé écrire un Nat-HOWTO mais, de toutes façons, personne ne
lis les HOWTOs...
--
---------------------------------------------------------
Éric Jacoboni « No sport, cigars! » (W. Churchill)
---------------------------------------------------------

[Herve Eychenne]

Sebastien Blondeel <blon...@news.ens.fr> wrote:

>> Je comprends rien au langage de Nat :( ....suis je normal ?

> Tu es logé à la même enseigne que nous tous ici, mais plus honnête que
> ceux qui font semblant de comprendre en répondant.

Bon, étant donné que j'ai répondu, je suppose que je devrais me sentir
visé.
Tu devrais le savoir, ce n'est pas parce qu'on répond qu'on comprend tout.
Les posts sont longs, et on a pas toujours quelque chose à dire sur toutes
ses parties. Et puis, chacun poursuit un peu sa petite idée.
C'est la loi d'Usenet. ;-)

Soyons clair, je suis loin de maîtriser tous les concepts dont Nat
fait état.
Les deux sujets les plus ardus évoqués par lui sont les meta-objets, et
Common Lisp.
Je suis un peu familier du premier, pas vraiment du deuxième. C'est
pourquoi je me suis bien gardé de répondre aux passages les plus
costauds. Nat pose beaucoup de problèmes, que l'on peut comprendre
sans avoir pour autant de solution à proposer.
C'est mon cas. Ca va peut-être mieux en le disant.

De toute manière, je ne vise pas si haut, et ça tombe bien, j'en serais
incapable.
D'ailleurs, comme cela a déjà été dit, être trop ambitieux et partir dans
de belles théories serait certainement voué à l'échec en matière de
logiciel libre.

> C'est la thèse de l'octroi : il faut avoir fait quinze ans d'études pour
> commencer à comprendre ce qu'il raconte.

Je n'ai que mes années d'études d'élève ingénieur en informatique derrière
moi pour ce qui est du côté purement théorique, et malgré ce n'est
certainement pas mes 16 ans d'informatique qui me feront penser que
cette belle science n'a plus de secret pour moi, loin s'en faut.
Que les choses soient claires.

RV

P.S.: je ne connais pas la thèse de l'octroi. Je le dis par précaution,
parce que sinon certains risqueraient de penser que je le sais,
étant donné que j'ai répondu à ce post.

[Thierry Pinelli]

In article <3731f46c...@news.club-internet.fr>
l'excellent mpu...@mail.dotcom.fr écrivait :

>Je comprends rien au langage de Nat :( ....suis je normal ?

NetWork Translation Address ou Netbios Auditing Tool ?

--
Quelqu'un ici a dit qu'il y avait une patch pour fider les bugs
de RedHat5 sur leur page ( www.redhat.com ) mais j'ai ps trouver ou qqun
pourrias me shooter l'adresse svp?
-+- Psionic in Guide du Linuxien pervers, "Tous drogués !!" -+-

[Nat Makarevitch]

Michael Pujos writes:

> Il suffit d'ecrire un HOWTO-HOWTO , pour dire aux gens de lire les
> HOWTO.

:-)))
o, c'est bien connu : les HOWTO on peut en mettre des tas (méta ?) et on en
fait état (dans les réponses aux questions classiques).

[Nat Makarevitch]

Herve Eychenne writes:

>>> Je comprends rien au langage de Nat

>> plus honnête que ceux qui font semblant de comprendre en répondant.

> Bon, étant donné que j'ai répondu, je suppose que je devrais me sentir
> visé.

n, n, tt va bien : Sbi trolle :-)

>> C'est la thèse de l'octroi

> je ne connais pas la thèse de l'octroi

une idée simple : il me semble que l'on 'paie' le rendement (gains
quantitatifs et qualitatifs) par l'apprentissage. j'appelle 'octroi' ce
'coût' d'accès à la connaissance grâce à laquelle on travaille plus vite
et/ou mieux, et avais tenté un parallèle avec l'apprentissage de la
lecture/écriture (long et parfois douloureux, mais 'rentable'). cette «
thèse de l'octroi », appliquée à Linux, permet par exemple de déclarer
préférable d'apprendre à rédiger de petits scripts plutôt que de se
contenter d'une interface limitée, qui interdit toute 'automatisation' des
tâches à accomplir. cette parabole me coûte à présent (est-ce l'octroi
de la thèse de l'octroi ?) car, à présent, tt le monde et son Sbi récupère
et détourne afin de troller :-)

[Nat Makarevitch]

Marc SCHAEFER writes:

>> les laisser en txt a beaucoup d'avantages : engendrement/traitement
>> automatique facilité et surtout mode dégradé plus facile à gérer

> Aussi, un mode texte peut rendre les ``diff''

ah, o, bien vu. cela rend donc aussi possible la 'gestion de configuration'
(versioning) et facilite la sauvegarde. avec une approche en 'make
implicite' on ne paie mm pas d'octroi (à n, pas encore cela !) côté perfs.

[Nat Makarevitch]

Herve Eychenne writes:

>> quels critères doit-on prendre en considération ?

> Difficile à dire... Quand je vois une belle chose, je sais la
> reconnaître.

notre quête de formalisme restera probablement vaine car nul ne sait
comment la satisfaire. pis : elle est sans doute inutile car les
développeurs exercent cette faculté de 'reconnaître' les approches
adéquates, et 'élisent' les projets correspondants en y participant. cela
ne ns ramène cependant pas au pt de départ car ns avions alors
implicitement considéré comme nécessaire d'orienter leurs choix afin
d'éviter les redondances, alors qu'une tentative de clarification souligne
l'inutilité de ces dispositions.

méta : il suffirait de créer des projets fédérateurs de projets :-) mais
écueil : il faut formaliser leurs descriptions. n, on ne pose pas ainsi un
paradoxe, car avons a évacué la contrainte, jusqu'alors forte même si
seulement sous-entendue, de forger le prj unificateur en tentant de «
complaire » aux développeurs potentiels.

> pour un projet actif, si le(s) développeur(s) ne veulent pas entendre
> raison, le fork semble inévitable.

> on peut espérer que les utilisateurs choisiront le nouveau projet,
> puisqu'il est bon

si le fork était justifié ce 'fils' dépassera le produit du prj père, et
s'imposera naturellement. mais, en pratique, les users choisissent en
fonction de leurs attentes, qui ne coïncident qu'imparfaitement avec leurs
intérêt réels (surtout à long terme). le 'fils' doit donc, parfois, vivre
dans un tunnel (période durant laquelle il n'intéresse que ses
développeurs) dont il ne sortira (peut-être) qu'à l'occasion d'une prise de
conscience ou, plus vraisemblablement, que lorsque les limites des autres
prj deviendront patentes.

un exemple : GNUstep

>>> Je crois difficilement au hasard en informatique.

>> il sévit (ou accorde) pourtant partout, y compris en info.

> Je ne vois pas vraiment en quoi...

eh bien, par exemple, à cause de l'argument d'autorité combiné à la
perspective historique. les logiciels que ns employons aujourd'hui ont été
réalisés par des gus disposant d'un certain bagage et aux dispositions
d'esprit données. tt cela ne procède souvent que du hasard, car chacun
acquiert des connaissances au gré du besoin (souvent 'externe' au processus
même d'acquisition de la connaissance). exemple : l'appli que tu grattes
aujourd'hui doit beaucoup à ce que tu a appris, qui dépend directement de
ton cursus, lequel dépend (au moins un peu) au hasard : une méthode étudiée
durant un cours assuré par tel professeur (qui, cette année là, était
présent car ne déménagea qu'un an plus tard), un langage assimilé durant un
stage ...

tt cela joue aussi lorsque tu codes : telle structure de donnée, tel mode
d'analyse de l'ensemble (...) relèvent par exemple d'un commentaire lâché
par un tiers, sans qu'aucune pré-détermination (sur le plan ontologique)
apparente n'opère.

cet exposé est difficile à rendre 'utile' car demeure trop transposable,
joue sur ttes les disciplines. mais il pose à mon sens les limites de nos
tentatives de formalisation.

encore un exemple : GNUstep (www.gnustep.org). pourquoi ce prj est-il
adossé à Objective-C ? son développeur avait peut-être apprécié ce langage,
enseigné par je ne sais quel gus ayant « autorité » sur lui (accordée par
l'élève ou acquise par la contrainte) ou bien étudié après une découverte
perso (hasard ...). quels en st, à présent, les effets ? plutôt néfastes,
car peu de développeurs rallient ce prj pourtant prometteur. mais
l'illustre NEXTStep, son ancêtre, existerait-il si son concepteur n'avait
pas connu Obj-C ? ce choix condamne-t-il à présent GS ? où est l'outil, le
produit ? où est la cause, la condition nécessaire ? hasard, hasard,
hasard ... comme partout et tjrs.

> un vrai informaticien serait sans doute capable de s'enfermer de la sorte
> pendant 5 ans... ;-)

j'en suis !

> Une autre méthode consiste au contraire à placer dans la bibliothèque
> les fonctions relatives à l'implémentation la plus avancée, un peu
> comme le VFS qui est quasiment une copie de l'interface de ext2.

> certaines fonctions ne seraient pas disponibles sur les
> applications plus limitées

comment dresser a priori la liste des services assurés par une
bibliothèque ? on peut la mettre en forme à partir de la 'whishlist' des
utilisateurs potentiels du programme, car cette dernière répond à la
question 'pourquoi ?' qui, somme toute, correspond bien à la 'réponse'
qu'offre une API

> à force de viser l'universalité, on n'atteint pas le but principal:
> fournir quelque chose d'utilisable par un être humain

o !!

> Peut-être la stratégie du "grignotage" est-elle plus conforme au modèle
> de développement libre

cas le plus souvent observé, en effet.

> Autant mettre toutes les applis à la mode Corba

prometteur.

> Programmation:
> - L'application doit être

> - disponible sous un maximum d'architecture
> - internationalisable

o
mais tt cela crée, pour le développeur, des contraintes externes car elles
n'enrichissent pas le registre fonctionnel du programme

> - Le programmeur doit se concentrer autant que possible sur ce qu'il sait

> faire de mieux:
> programmer.

o
mais cela lui ramène le nez ds le guidon, aux dépens de la spécification

> Dans ce qui suit

je ne reprendrai que ce que je souhaite commenter. le reste : OK

> Configuration:
> - Toute modification de la configuration doit être formalisée dans un
> fichier enregistrable.

[ ... ]

l'intégration de cette somme d'exigence mène à un constat : tte application
doit être extensible au moyen d'un langage grâce auquel l'utilisateur peut
l'employer et la paramétrer

> Ergonomie:
> - le fonctionnement doit être assez transparent par défaut

> mais aussi détaillé que possible pour celui qui souhaite savoir ce qui
> est effectué.

ceci joue aussi en faveur d'un langage built-in, et ajoute mm à l'intérêt
des approches reflexives (=> le langage d'extension est aussi celui
qu'emploient les développeurs pour réaliser l'appli)

> - A chacun de choisir son niveau d'abstraction.
> Pourquoi ne pas envisager plusieurs niveaux de "difficulté"

> afin de permettre à l'utilisateur de progresser graduellement

j'aime beaucoup cette idée. quelqu'un (L. Fievet, si ma mémoire ne trahit
pas), avait un jour parlé de coder d'une interface qui évoluerait peu à peu
en dévoilant à l'utilisateur un nombre de possibilités augmentant avec son
expérience.

> Interfaces interactives:
> - Il est préférable de commencer le développement par une commande shell
> non-interactive. Puis, développer une interface interactive sous shell

o !

> Puis, l'application doit être implémentée sous X-Window

à mon sens il peut s'agit d'un 'module client', désolidarisé de
l'application (=> tte appli devrait être accessible via telnet, donc à un
autre programme)

> - le dialogue inter-applications doit être prévu

XML offre d'intéressantes perspectives : les canaux d'échanges de données
ne seraient que des backends

> - L'état d'une application interactive doit pouvoir être sauvegardé autant
> que possible

> - Dans le cas idéal (difficile, et même parfois impossible à réaliser),
> une commande X ainsi interrompue doit pouvoir être continuée en mode
> texte

> - Par extension, il serait envisageable de transférer une session active
> (ou pas) sur une autre machine.

Condor (assure mm le checkpoint/restart) !

[Herve Eychenne]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:

>>>> Je crois difficilement au hasard en informatique.

>>> il sévit (ou accorde) pourtant partout, y compris en info.

>> Je ne vois pas vraiment en quoi...

> chacun acquiert des connaissances au gré du besoin
> [...]

> une méthode étudiée durant un cours assuré par tel professeur (qui,
> cette année là, était présent car ne déménagea qu'un an plus tard),
> un langage assimilé durant un stage ...
> tt cela joue aussi lorsque tu codes : telle structure de donnée, tel mode
> d'analyse de l'ensemble (...) relèvent par exemple d'un commentaire lâché
> par un tiers

Dans ce sens-là: soit...

> encore un exemple : GNUstep (www.gnustep.org). pourquoi ce prj est-il
> adossé à Objective-C ? son développeur avait peut-être apprécié ce langage,
> enseigné par je ne sais quel gus ayant « autorité » sur lui (accordée par
> l'élève ou acquise par la contrainte) ou bien étudié après une découverte
> perso (hasard ...). quels en st, à présent, les effets ? plutôt néfastes,
> car peu de développeurs rallient ce prj pourtant prometteur. mais
> l'illustre NEXTStep, son ancêtre, existerait-il si son concepteur n'avait
> pas connu Obj-C ? ce choix condamne-t-il à présent GS ? où est l'outil, le
> produit ? où est la cause, la condition nécessaire ? hasard, hasard,
> hasard ... comme partout et tjrs.

Oui. Il existe aussi de trop rares contre-exemples.
Emacs participe un peu à la popularisation du Lisp, par exemple.
De même que Gnome est entrain de familiariser un certain nombre de
développeurs avec Corba.

>> un vrai informaticien serait sans doute capable de s'enfermer de la sorte
>> pendant 5 ans... ;-)

> j'en suis !

Malheureusement, moi aussi. Mais j'essaye de me soigner tant bien que mal. ;-)

>> Une autre méthode consiste au contraire à placer dans la bibliothèque
>> les fonctions relatives à l'implémentation la plus avancée, un peu
>> comme le VFS qui est quasiment une copie de l'interface de ext2.
>> certaines fonctions ne seraient pas disponibles sur les
>> applications plus limitées

> comment dresser a priori la liste des services assurés par une
> bibliothèque ?
> on peut la mettre en forme à partir de la 'whishlist' des
> utilisateurs potentiels du programme, car cette dernière répond à la
> question 'pourquoi ?' qui, somme toute, correspond bien à la 'réponse'
> qu'offre une API

Oui. On peut aussi se baser sur l'existant en commençant par la somme des
fonctionnalités assurées par l'existant.
Puis rajouter les souhaits de chacun.

>> Autant mettre toutes les applis à la mode Corba

> prometteur.

Gnome pourrait être la bonne amorce.

>> Programmation:
>> - L'application doit être
>> - disponible sous un maximum d'architecture
>> - internationalisable

> o
> mais tt cela crée, pour le développeur, des contraintes externes car elles
> n'enrichissent pas le registre fonctionnel du programme

A la limite, ce n'est pas bien grave si l'auteur de n'en charge pas
directement lui-même. Il est tout à fait faisable de porter le programme
sous autoconf et gettext, même quand celui-ci a atteint une taille
raisonnable. Et cela peut être effectué sans trop de pb par un tiers qui
maîtrise bien ces outils.
Mais bien sûr, il est plus pratique de le faire dès le début.

Pour gettext, il faut rajouter des _() autour des chaines (à la mode GNU)
et rédiger le .po.
Pour autoconf, on peut tout simplement compiler le source sur l'architecture
désirée et régler les problèmes un par un.

>> - Le programmeur doit se concentrer autant que possible sur ce
>> qu'il sait faire de mieux: programmer.

> o
> mais cela lui ramène le nez ds le guidon, aux dépens de la spécification

Programmer ne veut pas dire pour moi se jeter sur le clavier et pisser du
code. C'est aussi réfléchir avant, pendant, et même après avoir codé.

>> Dans ce qui suit

> je ne reprendrai que ce que je souhaite commenter. le reste : OK

idem

>> Ergonomie:
>> - le fonctionnement doit être assez transparent par défaut

>> mais aussi détaillé que possible pour celui qui souhaite savoir ce qui
>> est effectué.

> ceci joue aussi en faveur d'un langage built-in, et ajoute mm à l'intérêt
> des approches reflexives (=> le langage d'extension est aussi celui
> qu'emploient les développeurs pour réaliser l'appli)

Cela pose tout de même un petit problème de performances.
A moins de pouvoir compiler ce langage.

>> - A chacun de choisir son niveau d'abstraction.
>> Pourquoi ne pas envisager plusieurs niveaux de "difficulté"
>> afin de permettre à l'utilisateur de progresser graduellement

> j'aime beaucoup cette idée. quelqu'un (L. Fievet, si ma mémoire ne trahit
> pas), avait un jour parlé de coder d'une interface qui évoluerait peu à peu
> en dévoilant à l'utilisateur un nombre de possibilités augmentant avec son
> expérience.

Mais pas dans le style "astuce du jour" que l'on finit par faire disparaître
ou désactiver complètement, hein ! ;-)
Je pense à une sorte de masquage successif, car il ne faut pas que
l'utilisateur soit perdu en changeant de niveau (i.e. pas de boulversement,
juste une extension).
Et le changement de niveau serait plutôt volontaire, parce qu'un changement
basé sur une évaluation floue du niveau de l'utilisateur risquerait
d'être un peu déroutant également.
Je n'ai jamais vu d'application utilisant un tel concept... Quelqu'un
en connaît-il une ? (sous Linux de préfèrence... je n'ai *que* ça... ou
plutôt, j'ai *tout* ça !)

>> Puis, l'application doit être implémentée sous X-Window

> à mon sens il peut s'agir d'un 'module client', désolidarisé de

> l'application (=> tte appli devrait être accessible via telnet, donc à un
> autre programme)

Tu veux dire, faire un telnet sur un port donné (>1024, déjà) et piloter
l'appli au clavier à distance ?

>> - le dialogue inter-applications doit être prévu

> XML offre d'intéressantes perspectives : les canaux d'échanges de données
> ne seraient que des backends

Afin d'éviter de me faire octroyer je ne sais quoi par Sbi, je préfère te
demander un complément d'info. ;-)

>> - L'état d'une application interactive doit pouvoir être sauvegardé autant
>> que possible
>> - Dans le cas idéal (difficile, et même parfois impossible à réaliser),
>> une commande X ainsi interrompue doit pouvoir être continuée en mode
>> texte
>> - Par extension, il serait envisageable de transférer une session active
>> (ou pas) sur une autre machine.

> Condor (assure mm le checkpoint/restart) !

Ah oui ? Il s'agit bien de ce projet de clustering en espace utilisateur
basé sur du PRELOAD ? (dommage qu'ils ne livrent pas les sources,
d'ailleurs)
Si c'est bien ça, cela ne concerne pas vraiment les applications X, donc,
mais plutôt les applications en général.

RV

[Michel BILLAUD]

Nat Makarevitch <n...@nataa.fr.eu.org> writes:

> notre quête de formalisme restera probablement vaine car nul ne sait
> comment la satisfaire. pis : elle est sans doute inutile car les
> développeurs exercent cette faculté de 'reconnaître' les approches
> adéquates,

Et de s'adapter aux approches inadéquates. Voire de s'y accrocher.

Pessimisme du lundi.

Tiens une idée. J'entends "noyau en C++". Pourquoi pas.
Le noyau ELKS, qui est encore minuscule (par rapport a LINUX),
ne serait-il pas un bon candidat à la plusplusification ?
Montrez nous le code :-)

MB
--
Michel BILLAUD : bil...@labri.u-bordeaux.fr
LABRI - Universite Bordeaux I : phone W: 0556846922 /0556845792
351, cours de la Liberation : http://www.labri.u-bordeaux.fr/~billaud
33405 Talence (FRANCE) : http://dept-info.labri.u-bordeaux.fr/~billaud

[devivie . enserb . u-bordeaux . fr]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:
| devivie writes:

|> Ce serait pourtant sympa d'avoir une belle conception OO du noyeau

|pourquoi ? tu devrais argumenter ! :-)

Permettre une meilleure "séparation des pouvoirs" (c)Montesquieu !

AMHA, l'OO permet d'offrir cette séparation qui est très recherchée
dans les conceptions micro-noyeau tout en offrant les avantages du
monolithique (appel de fonction +rapide que message-passing). Mettre
des barrières explicites clarifieraient le rôle de chaque composant.
Pas exemple: une classe "syscall" qui prend en charge l'aspect
politique tandis que les classes "drivers" s'occuperaient de
l'execution.

D'autres arguments plaident en faveur de l'OO:
-Vu la taille des sources, le choix de l'OO permettrait des
adaptations et une validation globale plus simple.
-Une meilleure factorisation du code (ce qui va aussi dans le sens
des performances car on a une meilleure localité des données ;)
-Des interfaces précises et un design par classes simplifieraient
grandement le travail de compréhension de ceux qui souhaitent y
travailler (et par conséquent accélèreraient sans doute le
développement !)

Et je suis sûr que n'importe qui peut en trouver d'autres (en étant
un peu sensibilisé au génie-log ;).

[Herve Eychenne]

Thierry Pinelli <tpin...@pinux.gyptis.frmug.org> wrote:

> l'excellent mpu...@mail.dotcom.fr écrivait :

>>Je comprends rien au langage de Nat :( ....suis je normal ?

> NetWork Translation Address ou Netbios Auditing Tool ?

^^^^^^^^^^^^^^^^^^^^^
C'est un troll ? ;-)

[devivie . enserb . u-bordeaux . fr]

Michel BILLAUD <bil...@labri.u-bordeaux.fr> wrote:

|Tiens une idée. J'entends "noyau en C++". Pourquoi pas.
|Le noyau ELKS, qui est encore minuscule (par rapport a LINUX),
|ne serait-il pas un bon candidat à la plusplusification ?
|Montrez nous le code :-)

Même si ELKS est minuscule, un tel projet reste très ambitieux.

C'est un projet qui me tente mais étant déjà en projet, je n'ai
pas assez de temps actuellement.

[devivie . enserb . u-bordeaux . fr]

Herve Eychenne <eych...@info.enserb.u-bordeaux.fr> wrote:

|Une autre méthode consiste au contraire à placer dans la bibliothèque
|les fonctions relatives à l'implémentation la plus avancée, un peu
|comme le VFS qui est quasiment une copie de l'interface de ext2.

Et pour sauter du coq à l'âne, voilà encore un argument en faveur
d'une c++isation de linux: tu construits VFS avec une classe
abstraite dont ext2 hérite ! Exit la duplication de code ;)

j. qui aime radoter ;)

[devivie . enserb . u-bordeaux . fr]

devivie @ info . enserb . u-bordeaux . fr wrote:

|Et je suis sûr que n'importe qui peut en trouver d'autres (en étant
|un peu sensibilisé au génie-log ;).

Un autre: la gestion des exceptions au lieu du bazar classique (panic
+ oops + kernel msg + retour de fonction & test systématique).

j.

[devivie . enserb . u-bordeaux . fr]

Nat Makarevitch <n...@nataa.fr.eu.org> wrote:

|je connais mal ML. ils sont en effet plutôt différents

ML: langage fonctionnel, fortement typé. Sa syntaxe est beaucoup
plus lisibles que les traditionnelle (()(())))(). C'est un très bel
exemple pour le polymorphisme (marche avec des fonctions d'ordres
supérieurs et autres truc sioux de chercheurs comme le lambda-calcul)

La gestion des exceptions et de la mémoire est en standard. Mais le
truc le plus remarquable c'est tout le système de type qui gère très
bien les conflits coercition/surcharge ainsi que l'_inférence_ (déduction
du type par unification: dans "A/B", si B est entier et que rien n'est
précisé pour le reste, le compilo déduit le type de A et de A/B donc
pas besoin de le préciser ;) .

Ocaml est une extension objet de ML. C'est un langage gaulois qui est
relativement académique :) Il doit être dispo sur le site de l'INRIA.

Bien sûr, ces langages sont inconcevables pour du développement système !

[Jerome Vouillon]

devivie @ info . enserb . u-bordeaux . fr writes:

> AMHA, l'OO permet d'offrir cette séparation qui est très recherchée
> dans les conceptions micro-noyeau tout en offrant les avantages du
> monolithique (appel de fonction +rapide que message-passing). Mettre
> des barrières explicites clarifieraient le rôle de chaque composant.
> Pas exemple: une classe "syscall" qui prend en charge l'aspect
> politique tandis que les classes "drivers" s'occuperaient de
> l'execution.
>
> D'autres arguments plaident en faveur de l'OO:
> -Vu la taille des sources, le choix de l'OO permettrait des
> adaptations et une validation globale plus simple.
> -Une meilleure factorisation du code (ce qui va aussi dans le sens
> des performances car on a une meilleure localité des données ;)
> -Des interfaces précises et un design par classes simplifieraient
> grandement le travail de compréhension de ceux qui souhaitent y
> travailler (et par conséquent accélèreraient sans doute le
> développement !)

En remplaçant "classe" par "module", tout ce que tu dis s'applique
très bien à la programmation modulaire. Ce ne sont aucunement des
arguments en faveur de la programmation à objets.

-- Jérôme

[Jerome Vouillon]

devivie @ info . enserb . u-bordeaux . fr writes:

> devivie @ info . enserb . u-bordeaux . fr wrote:
>
> |Et je suis sûr que n'importe qui peut en trouver d'autres (en étant
> |un peu sensibilisé au génie-log ;).
>
> Un autre: la gestion des exceptions au lieu du bazar classique (panic
> + oops + kernel msg + retour de fonction & test systématique).

Quel rapport entre exceptions et objets ?

-- Jérôme

[Nicolas Roard]

Jerome Vouillon a écrit :

>
> Quel rapport entre exceptions et objets ?
>

Aucun, si ce n'est que C++ gère les exceptions ?

>
> -- Jérôme

Nico

[Michel BILLAUD]

devivie @ info . enserb . u-bordeaux . fr writes:

> Michel BILLAUD <bil...@labri.u-bordeaux.fr> wrote:
>
> |Tiens une idée. J'entends "noyau en C++". Pourquoi pas.
> |Le noyau ELKS, qui est encore minuscule (par rapport a LINUX),
> |ne serait-il pas un bon candidat à la plusplusification ?
> |Montrez nous le code :-)
>
> Même si ELKS est minuscule, un tel projet reste très ambitieux.

C'est-a-dire que ça nécessiterait trop de travail par rapport au
résultat attendu ?

> C'est un projet qui me tente mais étant déjà en projet, je n'ai
> pas assez de temps actuellement.

et la marge du listing est trop petite, aurait dit l'autre.

[devivie . enserb . u-bordeaux . fr]

Michel BILLAUD <bil...@labri.u-bordeaux.fr> wrote:
|devivie @ info . enserb . u-bordeaux . fr writes:

|> Même si ELKS est minuscule, un tel projet reste très ambitieux.

|C'est-a-dire que ça nécessiterait trop de travail par rapport au
|résultat attendu ?

Le résultat n'en vaut-il pas la chandelle ? Il suffit de motiver
suffisament de personnes pour diviser le travail (effet GNU !).

|> C'est un projet qui me tente mais étant déjà en projet, je n'ai
|> pas assez de temps actuellement.

|et la marge du listing est trop petite, aurait dit l'autre.

Fermat ? ;)

...mes pretextes ne semblent pas te convaincres :(

[devivie . enserb . u-bordeaux . fr]

Jerome Vouillon <Jerome....@inria.fr> wrote:

|En remplaçant "classe" par "module", tout ce que tu dis s'applique
|très bien à la programmation modulaire. Ce ne sont aucunement des
|arguments en faveur de la programmation à objets.

Connais-tu bien le C++ pour écrire ca ? Bien sûr, on peux simuler
des objets avec du C et essayer de rendre le tout modulaire, mais
on arrivera jamais au même résultat: C++ ajoute la classe qui est
une unité d'encapsulation plus précise que ce que l'on peux
faire en C avec un style modulaire. La porté de classe est mieux
que le simple extern ou static. De plus les mots clefs public,
protected & private permettent de mieux délimiter l'interface et
l'implémentation (.h/.c).

L'avantage intrinsèque d'une approche objet est de poser le
problème des *responsabilités* avec plus d'acuité. La phase de
conception demande peut-être plus de travail que dans un style
procédural mais le résultat est meilleur. Quel va être le résultat
de la collaboration de plusieurs milliers de personnes si tout
n'est pas bien spécifier ?

Les arguments en faveurs du C sont plus de l'ordres techniques que
ceux pour le C++ ; ils ne me semblent pas suffisant pour rejetter
l'objet qui est plus "naturel" pour les gros projets. Il faut sans
doute approfondir la question au lieu de rejetter systématiquement
tout changement en bloc.

AMHA, le langage source doit permettre d'*exprimer* un problème le plus
naturellement possible: certains pbs s'exprimeront sans doute mieux
avec une approche procédurale, d'autres nécéssiterons un langage
fonctionnel, objet, logique ou autre. Mais le langage n'est certainement
pas le premier élément à considérer pour résoudre les problèmes d'ordre
pratiques (performance et cie...) . Ca c'est le problème du compilateur
voir de certaines librairies complètements optimisés (BLAS pour ceux qui
connaissent le massivement parallèle) et non celui du langage !

Je sais qu'il y a beaucoups de C-iste dans la communauté linux mais
je ne comprends pas le type de raisonnement (C++ est une extension
de C) => (les programmes C++ sont +gros et +lent que leurs homolgues
en C).

[devivie . enserb . u-bordeaux . fr]

Nicolas Roard <nro...@e-motive.com> wrote:

|Aucun, si ce n'est que C++ gère les exceptions ?

Yep !

Tiens encore un autre: C++ est plus élastique aux changements.