En même temps quand on s'appelle Nicolas Delsaux aussi on peut se renseigner... (et je ne prétends pas avoir la vérité absolue, mais bon quand on commence par « C'est un tissu d'âneries ou quoi ? » pour ensuite critiquer sans argument quelqu'un qui a déjà fait énormément de choses (qu'on l'on aime ou pas)...)
L'un des avantages de l'industrie informatique, c'est son pragmatisme. Si Bill Gates fait une connerie, n'importe qui ici lui dira (s'il le peut). De la même manière, le fait que Stallman ait écrit un tas de choses pour le libre ne signifie pas qu'il aura raison à tous les coups. Et en l'occurence, ce document est un tissu d'inepties. Par exemple, quand il dit
i vous développez un programme Java sur la plate-forme Java de Sun, vous êtes voués à utiliser de fonctionnalités Sun exclusives sans même vous en rendre compte.
Il se gourre grave. Toutes les classes fournies dans la JVM de Sun, comme dans les autres, sont définies et évoluent grâce au JCP (ou Java Community Process) sur lequel je vous laisse vous documenter librement, mais qui est nettement ouvert dans son processus d'évolution. Il garantit par ailleurs que les fonctionnalités d'une JVM qui y sont définies (en clair, tout les packages java.* ou javax.*) sont standardisés dans leur interface et dans leur implémentation.
Alors, évidement, je ne sais pas si le JCP respecte complètement la Philosophie du Libre comme il l'entend. Mais pour moi, je sais que je peux influencer les JSR en cours, et donc faire évoluer Java dans ma direction. Et ça me suffit largement.
De la même manière, l'argument selon lequel il fallait "sauver" (sous-entendu pour le libre) le C, parce que c'était le seul langage existant, et le shell, parce que bon, sinon, compiler, c'est pas gagné, mais que Java ne mérite pas ce sauvetage parce que l'arche du libre n'est pas assez grande tient vachement la route, mais alors avec une classe folle.
Et puis, terminer par une exhortation à aller vérifier sur le site de la FSF que le programme utilisé est bien libre, ça fait plus concours de hits à l'ancienne qu'autre chose. Surtout quand on compte le nombre de programmes Java majeurs Open Source (au choix Eclipse, Tomcat, Ant, JBoss, NetBeans, Struts (enfin, ça, c'est pas un bon exemple), Beehive, ...).
Bref, pour moi, ça sonne beaucoup plus comme une espèce de message du vieux développeur C bien content d'être libre etr qui nous emmerde tous que comme autre chose.
Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).
Ca, c'est étayé, comme argument. Il y a des tonnes de différences, et alors ? La JVM est, quelquesoit son constructeur, censée être un processeur virtuel fonctionnant à la base comme interpréteur de bytecode en code machine pour 'larchitecture cible.
Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ? Faites plutôt vos opérations sur les coprocesseurs vidéo, au firmware nettement plus libre ?
[^] # Re: Java trap
Posté par Nicolas Delsaux . En réponse à la dépêche Brèves Java. Évalué à 2.
L'un des avantages de l'industrie informatique, c'est son pragmatisme. Si Bill Gates fait une connerie, n'importe qui ici lui dira (s'il le peut). De la même manière, le fait que Stallman ait écrit un tas de choses pour le libre ne signifie pas qu'il aura raison à tous les coups. Et en l'occurence, ce document est un tissu d'inepties. Par exemple, quand il dit
i vous développez un programme Java sur la plate-forme Java de Sun, vous êtes voués à utiliser de fonctionnalités Sun exclusives sans même vous en rendre compte.
Il se gourre grave. Toutes les classes fournies dans la JVM de Sun, comme dans les autres, sont définies et évoluent grâce au JCP (ou Java Community Process) sur lequel je vous laisse vous documenter librement, mais qui est nettement ouvert dans son processus d'évolution. Il garantit par ailleurs que les fonctionnalités d'une JVM qui y sont définies (en clair, tout les packages java.* ou javax.*) sont standardisés dans leur interface et dans leur implémentation.
Alors, évidement, je ne sais pas si le JCP respecte complètement la Philosophie du Libre comme il l'entend. Mais pour moi, je sais que je peux influencer les JSR en cours, et donc faire évoluer Java dans ma direction. Et ça me suffit largement.
De la même manière, l'argument selon lequel il fallait "sauver" (sous-entendu pour le libre) le C, parce que c'était le seul langage existant, et le shell, parce que bon, sinon, compiler, c'est pas gagné, mais que Java ne mérite pas ce sauvetage parce que l'arche du libre n'est pas assez grande tient vachement la route, mais alors avec une classe folle.
Et puis, terminer par une exhortation à aller vérifier sur le site de la FSF que le programme utilisé est bien libre, ça fait plus concours de hits à l'ancienne qu'autre chose. Surtout quand on compte le nombre de programmes Java majeurs Open Source (au choix Eclipse, Tomcat, Ant, JBoss, NetBeans, Struts (enfin, ça, c'est pas un bon exemple), Beehive, ...).
Bref, pour moi, ça sonne beaucoup plus comme une espèce de message du vieux développeur C bien content d'être libre etr qui nous emmerde tous que comme autre chose.
Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).
Ca, c'est étayé, comme argument. Il y a des tonnes de différences, et alors ? La JVM est, quelquesoit son constructeur, censée être un processeur virtuel fonctionnant à la base comme interpréteur de bytecode en code machine pour 'larchitecture cible.
Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ? Faites plutôt vos opérations sur les coprocesseurs vidéo, au firmware nettement plus libre ?