Débats autour du développement
logiciel, du projet Gnu / Linux et de l'histoire de la micro-informatique.
De :Philippe-Charles Nestel
Objet :Re: Informatique et profs >> un gouffre abyssal !!!
Groupes de discussion :fr.education.divers
Date :2003-07-21 07:43:36 PST
Christian wrote:
> Ici même, Philippe-Charles Nestel a écrit tantôt :
>
>
>> Qualifier la dichotomie libre/propriétaire de querelles de chapelles est
>> bien un discours de jésuite.
>
> C'est bien que ce soit considéré comme une dichotomie qui me dérange un
> peu.
Historiquement les logiciels ont d'abord été libres. Cette liberté était
naturelle et perdura jusqu'à l'époque des hackers du MIT.
Le logiciel propriétaire est venu comme une transgression et détruisit la
communauté de chercheurs du laboratoire d'intelligence artificielle du MIT.
Richard Stallman voyant le trouble psycho-social occasionné décida de fonder
la Free Software Foundation pour asseoir et protéger la communauté du
logiciel libre.
Ainsi naquit le projet GNU et la licence GPL.
Que tu ne saches pas faire de différence déontologique, en tant que
professeur d'une école fondée sur l'instruction publique entre un logiciel
propriétaire et un logiciel libre, entre un format de fichier breveté et un
format ouvert et/ou standardisé, entre un document pédagogique libre d'avec
un document propriétaire, est désolant.
> Il n'y a pas que du mauvais dans le logiciels propriétaires et que
> du bon dans les logiciels libres. Entre un mauvais libre et un bon
> propriétaire, je prend le bon...
>
Comme j'ai même pas envie de te répondre, ci-joint un copier/coller d'un
extrait d'une conférence de Sébastien Blondeel intitulée "Du logiciel libre
aux ressources collaboratives libres", tu comprendras peut être (sinon
c'est pas la peine de me répondre) l'intérêt de disposer du code-source.
Je considère chaque année depuis le milieu des années 80, que sur 900
élèves, existe au moins une dizaine d'élèves capable d'aller plus loin. Si
on leur file que de la microsofterie, il finiront au mieux par s'échanger
des DivX sur les ordinateurs portables Wireless que leur confiera le
Conseil Général, en plein cours, dans les Bouches-du-Rhône. Ce qui est plus
déjà pas si mal et moins ennuyeux en classe, sans oublier le "chat" bien
sûr.
Mais si on leur file du GNU/Linux, on va éveiller la curiosité des plus
curieux d'entre eux. Et à tous les coups, ou presque, la France s'assure
d'un renouvellement de ses ressources humaines.
Mais si tu ne pas piger cela, je vais finir par considérer que le petit
facho à l'origine du thread a raison de chier sur les petits bureaucrates
de l'enseignement.
---
Les logiciels sont écrits par des hommes. Au début c'était difficile et les
contraintes des premières machines étaient lourdes. Mais le temps a passé
et les programmeurs disposent maintenant d'environnements et de langages de
programmation conviviaux pour eux --- plus intuitifs, et éloignés de la
froideur mécanique de la machine.
L'aspect de la programmation destiné à être manipulé et partagé par des
hommes s'appelle le code source. Les machines utilisent, pour des raisons
historiques ou d'économie de place ou de vitesse, des codes binaires.
La transformation du code source en code binaire s'appelle la compilation.
Elle est menée par un compilateur, et elle détruit des méta-informations:
on ne peut pas remonter. On dispose de strictement moins de compréhension
de ce qui s'est passé dans l'esprit du programmeur si l'on ne dispose que
du code binaire; on en est presque réduit à un rôle de consommateur passif.
J'ai déjà illustré cela par des ateliers grand public, et récemment et
régulièrement, il m'arrive à titre personnel de vérifier l'intérêt de
disposer du code source.
Le code source est un peu comme la recette de cuisine: un gâteau une fois
sorti du four s'adressera directement aux papilles gustatives, qui en
apprécieront quasi primairement les qualités. Il sera très difficile d'en
retrouver la recette, et d'en fabriquer une version un peu plus sucrée ou
en remplaçant ceci par cela. Au contraire, le rédacteur de la recette aura
émaillé cette dernière de commentaires et de conseils pour la préparation,
qui disparaîtront lors de la réalisation de la recette.
Il n'est pas nécessaire d'avoir étudié l'informatique pour comprendre un
code source. Exemple:
#include <stdio.h>
int main () {
int compteur;
for (compteur = 1; compteur <= 10; compteur = compteur + 1) {
int carre, cube;
carre = compteur * compteur;
cube = carre * compteur;
printf("%d\t%d\t%d\n", compteur, carre, cube);
}
}
À l'exécution on obtient:
1 1 1
2 4 8
3 9 27
4 16 64
5 25 125
6 36 216
7 49 343
8 64 512
9 81 729
10 100 1000
Le code binaire a l'allure suivante:
0000000: 7f45 4c46 0101 0100 0000 0000 0000 0000 .ELF............
0000010: 0200 0300 0100 0000 1083 0408 3400 0000 ............4...
0000020: 1408 0000 0000 0000 3400 2000 0600 2800 ........4. ...(.
0000030: 1900 1800 0600 0000 3400 0000 3480 0408 ........4...4...
0000040: 3480 0408 c000 0000 c000 0000 0500 0000 4...............
[...]
00005b0: f682 0408 0683 0408 0000 0000 0047 4343 .............GCC
00005c0: 3a20 2847 4e55 2920 322e 3935 2e34 2032 : (GNU) 2.95.4 2
00005d0: 3030 3131 3030 3220 2844 6562 6961 6e20 0011002 (Debian
00005e0: 7072 6572 656c 6561 7365 2900 0047 4343 prerelease)..GCC
00005f0: 3a20 2847 4e55 2920 322e 3935 2e34 2032 : (GNU) 2.95.4 2
0000600: 3030 3131 3030 3220 2844 6562 6961 6e20 0011002 (Debian
0000610: 7072 6572 656c 6561 7365 2900 0047 4343 prerelease)..GCC
[...]
0000bb0: 0700 0000 0000 0000 0000 0000 dc06 0000 ................
0000bc0: 7800 0000 0000 0000 0000 0000 0100 0000 x...............
0000bd0: 0000 0000 0100 0000 0300 0000 0000 0000 ................
0000be0: 0000 0000 5407 0000 bf00 0000 0000 0000 ....T...........
0000bf0: 0000 0000 0100 0000 0000 0000 ............
Un minimum d'honnêteté intellectuelle m'oblige à signaler que si l'on a la
chance de disposer d'un code binaire non «strippé» on peut le faire parler
de manière un peu plus convaincante en utilisant un débogueur. On obtient
alors:
(gdb) disassemble main
Dump of assembler code for function main:
0x80483f0 <main>: push %ebp
0x80483f1 <main+1>: mov %esp,%ebp
0x80483f3 <main+3>: sub $0x18,%esp
0x80483f6 <main+6>: nop
0x80483f7 <main+7>: movl $0x1,0xfffffffc(%ebp)
0x80483fe <main+14>: mov %esi,%esi
0x8048400 <main+16>: cmpl $0xa,0xfffffffc(%ebp)
0x8048404 <main+20>: jle 0x8048408 <main+24>
0x8048406 <main+22>: jmp 0x8048440 <main+80>
0x8048408 <main+24>: mov 0xfffffffc(%ebp),%eax
0x804840b <main+27>: imul 0xfffffffc(%ebp),%eax
0x804840f <main+31>: mov %eax,0xfffffff8(%ebp)
0x8048412 <main+34>: mov 0xfffffff8(%ebp),%eax
0x8048415 <main+37>: imul 0xfffffffc(%ebp),%eax
0x8048419 <main+41>: mov %eax,0xfffffff4(%ebp)
0x804841c <main+44>: mov 0xfffffff4(%ebp),%eax
0x804841f <main+47>: push %eax
0x8048420 <main+48>: mov 0xfffffff8(%ebp),%eax
0x8048423 <main+51>: push %eax
0x8048424 <main+52>: mov 0xfffffffc(%ebp),%eax
0x8048427 <main+55>: push %eax
0x8048428 <main+56>: push $0x80484a4
0x804842d <main+61>: call 0x8048300 <printf>
0x8048432 <main+66>: add $0x10,%esp
0x8048435 <main+69>: incl 0xfffffffc(%ebp)
0x8048438 <main+72>: jmp 0x8048400 <main+16>
0x804843a <main+74>: lea 0x0(%esi),%esi
0x8048440 <main+80>: leave
0x8048441 <main+81>: ret
0x8048442 <main+82>: lea 0x0(%esi,1),%esi
0x8048449 <main+89>: lea 0x0(%edi,1),%edi
End of assembler dump.
Travaillant quasi-exclusivement avec du logiciel libre, je connais mal les
technique de déplombage et de décompilation. Vous aurez cependant compris
qu'il est bien plus difficile de comprendre ce que le programme fait, et de
le modifier pour le corriger, le faire évoluer, ou l'adapter aux besoins,
si on ne dispose pas de son code source.
Comment procéderiez-vous pour aller jusque 12 et non 10, en disposant:
du code source?
du code binaire?
d'un déboggeur?
Même question pour calculer les puissances quatre, travailler par
incréments de deux, etc.
Cet exemple peut sembler bébête et taillé sur mesure. Il en est exactement
de même avec la plupart des programmes. Nul besoin d'assimiler toute
l'architecture de l'arborescence de fichiers pour intervenir sur un point
de détail précis. J'ai un atelier à ce sujet utilisant le jeu affenspiel,
et récemment à titre personnel j'ai compris une limitation un peu laconique
d'un jeu vidéo de cette manière.
Ne diffuser que la version binaire, compilée, d'un programme revient donc à
ériger un obstacle gratuit et artificiel pour restreindre la souplesse
d'utilisation de ce produit par autrui.
---
Référence :
http://www.eleves.ens.fr/home/blondeel/tmp/20030411_LaLune/conf.html#htoc3
De :Pixelion
Objet :Re: Informatique et profs >> un gouffre abyssal !!!
Groupes de discussion :fr.education.divers
Date :2003-07-30 16:02:01 PST
"Philippe-Charles Nestel" a écrit
>Historiquement les logiciels ont d'abord été libres. Cette
>liberté était
>naturelle et perdura jusqu'à l'époque des hackers du MIT.
On a déjà passé par là, il me semble: c'est FAUX!
A l'origine, TOUS les logiciels étaient strictement propriétaires, au
point qu'on ne pouvait les faire tourner que sur une seule archétecture.
Le but était la vente de machines très chères, on ne prêtait pas trop
attention aux logiciels, mais malgré tout, c'était bien gardé. Ce n'est
que la révolution micro qui a fait tomber ce bastion et qui a rendu la
programmation accessible. Microsoft y a contribué. Pas toujours au
mieux, certes, mais ils sont toujours là, contrairement à des tas
d'entreprises plus que prometteuses.
Ou est Lotus, l'un des géants des années 80? Ou est WordPerfect? Il
sembre dans les tiroirs de Corel, il me semble... Et puis OS/2,
excellente architecture vendu par IBM, qui ne manquait pas de moyens...
quasiment disparu. Dommage: s'ils avaient su écouter les clients et les
développeurs comme Microsoft, ils auraient pu avoir beaucoup de succès.
Ce sont les erreurs de IBM qui sont responsables de l'échec de OS/2, pas
les "manipulations" de MS. Idem pour Mac: la totalité de l'échec de Mac,
qui aurait pu dominer le marché de l'informatique, revient à Apple, pas
à MS, qui a même fourni la première application réellement puissante sur
Mac: Excel.
Quant à Linux, c'est bien joli de distribuer quelque chose gratuitement,
mais ils ont totalement négligé l'utilisateur. Depuis 1 à 2 ans, les
distributions deviennent potables, mais arrêtez de dire qu'on aurait pu
filer ça à 90% des utilisateurs de Windows! Je n'ose pas m'imaginer le
cauchemar...
Si les adeptes de Linux avaient eu du sens commercial - veut dire qu'ils
se seraient intéressé à la question comment transformer leur jouet en
quelque chose d'utile pour le commun des mortels - alors ils auraient pu
concurrencer Windows au moins depuis 1995. Au lieu de ça, ils ont tous
fait de la masturbation intellectuelle. Je ne suis pas contre. J'ai fait
ça pendant très longtemps et c'est très amusant. Mais ça ne touche
qu'une infime minorité de l'humanité. Même Linus l'avait reconnu vers
1998. Après, il ne faut pas venir se plaindre du méchant Windows, qui
séduit les utilisateurs avec des millions de programmes utiles et de
jolies gadgets amusantes. C'est ce qu'il faut pour M. et Mme tout le
monde.
>Le logiciel propriétaire est venu comme une transgression et
>détruisit la communauté de chercheurs du laboratoire d'intelligence
>artificielle du MIT.
>Richard Stallman voyant le trouble psycho-social occasionné
>décida de fonder la Free Software Foundation pour asseoir et protéger la
>communauté du logiciel libre.
>Ainsi naquit le projet GNU et la licence GPL.
Le problème avec le "Libre", c'est qu'il oublie une composante très
importante: pour être commercialement viable, un logiciel doit être bien
plus qu'un bout de code. Il doit être fonctionnel et pouvoir s'adapter
aux beoins de l'utilisateur. Il faut donc du support et du customizing.
Pour cela, il faut le vendre, puis faire des contrats de maintenance
etc. Pour le vendre, il faut intéresser les vendeurs, qui eux ne
marchent que sur les marges. Dites à un vendeur "Le programme est
gratuit" et il vous dira "Je préfère vendre du Pepsi" - ou les
programmes Microsoft.
Le monde est fait comme ça: les techniciens ne savent pas parler aux
clients, il faut celui qui fait l'interface: le vendeur. Il rendre
possible le développement en assurant que les besoins du client sont
respectés par les programmeurs.
Le client, il s'en fout complètement de la manière dont son programme
fonctionne. Je peux vous le garantir: tout ce qui les intéresse, c'est
que quand on appuye sur un bouton, ça fait "truc" et sur l'autre, ça
fait "schmilblick" et ça ne pose cause pas de problèmes.
>Comme j'ai même pas envie de te répondre, ci-joint un
>copier/coller d'un
>extrait d'une conférence de Sébastien Blondeel intitulée "Du
>logiciel libre
>aux ressources collaboratives libres", tu comprendras peut
>être (sinon
>c'est pas la peine de me répondre) l'intérêt de disposer du
>code-source.
Il y a un intérêt à disposer du code source quand on développe avec ou
si on a du temps à perdre. Etant développeur, j'ai largement de quoi
faire avec mon propre code - dont je distribue le source à mes clients,
mais qui s'en foutent à de rares exceptions près - sauf pour mon système
de développement, évidemment.
Ne pas distribuer le code source peut être une très bonne stratégie,
d'ailleurs. Il est plus facile de gérer l'installation chez le client,
sa version etc. On peut aussi éviter qu'il fasse des bêtises ou qu'un
intrus ne puisse connaître quelques éléments confidentiels du code.
Je suis totalement contre l'idée de brevets logiciels. Par contre, il
est évident que les développeurs de grosses applications
professionnelles n'ont aucune envie de se faire piquer leur code par le
premier venu. Ca vous dépasse peut-être, mais la majorité des gens qui
font de la programmation ne sont pas des profs payés par l'Etat mais des
gens qui doivent gagner leur vie.
>Mais si on leur file du GNU/Linux, on va éveiller la
>curiosité des plus curieux d'entre eux. Et à tous
Je suis assez d'accord sur ce point: à ceux qui s'intéressent à la
technique, il faut donner des outils stimulants, complexes. Et eux, ils
ont beaucoup à gagner en pouvant étudier les sources des logiciels
libres. Mais ça ne les met pas en opposition avec les logiciels
propriétaires, c'est complémentaire. Il me semble inutile d'en faire
tout un fromage. Il y a des différences bien plus importantes.
Moi, je trouve catastrophique que le C et toutes ses variantes occupe
toujours le devant de la scène, avec la totalité des erreurs
conceptuelles graves toujours en place.
Un exemple parmi les pires: personellement, je déteste les accolades,
pour des raisons de lisibilité. Mais il y a pire: trouvez la différence
entre
if (...) then
...
if (...) then;
...
Elle est CATASTROPHIQUE. Une sonde sur Venus s'est plantée pour moins
que ça. Un langage qui permet de telles erreurs (et il y en a plein
d'autres) est CRIMINEL.
Encore pire: on enseigne un culte de la difficulté, du "guerrier de
l'impossible" chez les jeunes, qui pensent que c'est un signe de
réussite machiste d'arriver à surmonter ce genre de difficultés. Des
difficultés qui sont TOTALEMENT ARTIFICIELLES!
L'informatique est BIEN ASSEZ COMPLEXE. Il n'y a pas besoin d'en
rajouter! Le langage de programmation devrait être aussi clair que
possible, lisible avant tout pour l'être humain, facile à comprendre,
sans aucune complexité artificielle, sans pièges stupides et sans
incohérences. Il ne devrait pas inutilement multiplier les concepts et
n'avoir qu'une seule construction par concept. Et bien entendu, il doit
être rapide à implémenter, expressif, puissant et rapide.
Il y a plusieurs langages qui ont tenté l'expérience de satisfaire ces
exigeances. C/C++ sont à l'extrême opposé. Java fait la moitié du
chemin. Mais le seul que j'ai trouvé qui a adhéré à ces principes:
Oberon-2, le successeur de Pascal et Modula-2 par Prof. Wirth, qui a
couronné une longue carrière dans le domaine des langages de
programmation par cette création de génie.
Bon, assez de pub. Mais j'espère qu'on trouvera à l'avenir beaucoup plus
de code "libre" en Oberon-2 qu'en C/C++ et co. Surtout que des tas de
compilateurs sont disponibles sur toutes les plateformes - et bien
entendu de nombreux avec code source complet!
>les coups, ou presque, la France s'assure
"la France" est une abstraction et induit à penser en termes
collectivistes. Ce n'est pas le territoire "la France" qui a un
problème, mais de jeunes personnes qui doivent faire des choix
importants pour leur vie personelle et professionnelle.
>d'un renouvellement de ses ressources humaines.
On dirait un esclavagiste qui parle... on s'en fout, des ressources
humaines! Ce qui importe, c'est le bonheur de chacun, pas d'un
collectif, mais des individus.
Si tout le monde était content de se tourner les pouces "en France",
pourquoi se fatiquer? La réponse à cette question doit être donnée par
chacun individuellement. En sachant qu'il est SEUL RESPONSABLE de ses
choix et de ses résultats. Il peut se faire aider, se faire conseiller,
mais au bout du compte, il sera seul à vivre avec ses choix!
> Les logiciels sont écrits par des hommes. Au début c'était
>difficile et les
>contraintes des premières machines étaient lourdes. Mais le
>temps a passé
>et les programmeurs disposent maintenant d'environnements et
>de langages de
>programmation conviviaux pour eux --- plus intuitifs, et
>éloignés de la
>froideur mécanique de la machine.
Et pourtant, la programmation était infiniment plus simple en ces temps
là. On n'avait pas à faire à "une froide machine" mais à un truc rigolo
qui pouvait faire des tas de choses intéressantes. Et on pouvait
strictement se concentrer sur le problème, sans se soucier des standards
multiples, des derniers bugs du système x ou du logiciel de la version
y.
>pour des raisons
>historiques ou d'économie de place ou de vitesse, des codes
>binaires.
Alors là, vous me faites rire: pour des raisons "historiques"? Les
langages interprêtés, ça existe depuis la nuit des temps, mais l'idée de
créer un logiciel complexe avec, ça me dépasse. Je sais qu'il y a des
fous qui font ça - en Perl, par exemple - mais il faut vraiment être
masochiste.
Un compilateur fait bien plus que traduire: il assure la cohérence du
code et vérifie des invariants, les types de données, les déclarations
etc.
Il permet également la coopération à large échelle. En principe, le
partage du code n'est pas toujours la meilleure stratégie de
programmation en groupe. En réalité, il faudrait souvent appliquer le
principe de la "Black Box": seul l'interface est publiée. Ca permet
d'éviter des tonnes d'erreurs introduites par le fait que le programmeur
client d'une interface ne se base sur des connaissances internes du code
fourni par un autre groupe et qu'au moindre changement de celui-ci, le
client de ce module ne fonctionne plus. Ce sont les erreurs propagées
qui sont les plus difficiles à corriger.
On notera que le principe de MODULE est totalement absent de C et C++ et
que son implémentation sous Java et C# laisse à désirer.
> Travaillant quasi-exclusivement avec du logiciel libre, je
>connais mal les
>technique de déplombage et de décompilation. Vous aurez
>cependant compris
>qu'il est bien plus difficile de comprendre ce que le
>programme fait, et de
>le modifier pour le corriger, le faire évoluer, ou l'adapter
> aux besoins,
>si on ne dispose pas de son code source.
Franchement, si Word était disponible en code source, il faudrait me
payer très cher pour m'en approcher... je suis très content de ne pas
faire partie des pauvres masochistes qui doivent se farcir ce monstre.
A titre pédagogique, il peut être intéressant de lire du code existant,
surtout s'il est bien documenté et que la complexité est limitée. Sinon,
c'est une perte de temps. Il faut rapidement commencer à écrire du code
soi-même.
> Ne diffuser que la version binaire, compilée, d'un
>programme revient donc à
>ériger un obstacle gratuit et artificiel pour restreindre la
>souplesse d'utilisation de ce produit par autrui.
Je ne pense pas du tout! C'est une manière de protéger l'utilisateur
d'une complexité dont il n'a aucun besoin, sauf les rares personnes qui
font réellement de la programmation.
Diffuser le code source peut même être dangereux: il est d'autant plus
facile d'introduire des virus. Un code compilé est bien plus difficile à
manipuler. Il est en général possible de retrouver des traces de la
manipulation dans le code binaire, par pattern matching ou en cherchant
à certains endroits précis. Ce ne serait pas possible avec du code
source. Celui-ci permettrait une manipulation facile et indétectable,
sauf si on avait l'original sous la main. Ne resterait que la diffusion
sous forme signée cryptographiquement, ce qui ajouterait encore un
niveau de complexité pour l'utilisateur...
MS Office doit se composer d'au moins 10'000 fichiers sources
remplissant au moins 30 MB, plus les fichiers de ressources de 200 MB
qui permettraient finalement de générer l'exécutable, forcément compilé
(c'est déjà assez lent come ça). Le temps de compilation serait
probablement d'au moins 4h.
Non, merci. Je préfère savoir que c'est MS qui se charge du
dévelopoement. C'est leur problème. La seule chose qui rend le code
source réellement intéressant est l'abandon d'un logiciel par ses
auteurs.
Bonne chance avec l'enseignement. Si un jour vous souhaitez un cours par
quelqu'un qui a participé à la naissance de la micro depuis ses débuts,
qui a conçu 3 systèmes de développement (disponibles avec sources) et
d'innombrables applications et qui a un regard un peu différent sur ces
questions, je me ferais un plaisir de passer dans vos classes.
Et n'oubliez pas: A BAS LES BREVETS! Horreur suprême pour un monde fait
entièrement d'idées, l'appropriation des abstractions par l'appareil
politio-juridique.
Pix*
De :Pixelion
Objet :Re: Informatique et profs >> un gouffre abyssal !!!
Groupes de discussion :fr.education.divers
Date :2003-07-30 16:28:01 PST
Petit complément:
Ayant lu le document de Sébastien Blondeel, j'ai vu un passage où il
parle des "machines 8 bits des années 80" qui le font bien rire
maintenant. Personnellement, j'ai commencé bien avant, dans les années
70 et j'ai réalisé des applications tout à fait conséquentes sur un
ordinateur de poche 4 bits de 250g et en 17KB de mémoire: saisie de
données, calculs, impression de diagrammes avec lignes de haute tension
sur écran graphique et table traçante...
J'invite qui veut à faire mieux aujourd'hui. Actuellement, l'icône du
programme fait presque plus que 17KB.
On a bien plus de ressources, mais elles sont souvent très mal
utilisées, parce que les gens ne comprennent plus les bases de
l'informatique et quelques principes élémentaires. Plutôt que comprendre
les questions de complexité, on préfère se fier à la vitesse de la
machine et à une grosse mémoire.
Enfin juste pour signaler à tous les enseignants du groupe que le plus
important restent les bases universelles - dans TOUS les domaines.
Pix*