Java libre : un rêve devient réalité

Posté par  . Modéré par j.
Étiquettes :
0
13
nov.
2006
Java
Vous en avez rêvé, Sun l'a fait. Sun distribuera Java sous licence GPL. L'annonce sera faite via webcast ce 13 novembre, hier déjà la rumeur était propagée par TheServerSide.

Au sujet des détails techniques de cette nouvelle licence, la GPLv2 sera choisie. Pourquoi pas la GPLv3 ? Simplement car elle ne serait pas encore finie. En effet, Sun travaille avec la FSF sur cette version 3.

Comme on aurait pu s'y attendre, Sun va libérer petit à petit son bébé. La première partie à être libérée sera probablement le compilateur javac et HotSpot, la machine virtuelle, durant le premier semestre de 2007. J2EE et J2ME suivront le pas également et seront libérés.

Les composants libérés proviendront de Java 7, et non Java 6, celui-ci étant pratiquement terminé, et ne sera diffusé sous GPL que si le temps le permet. Cela aura pris un certain temps, mais Sun tient finalement sa promesse de libérer Java.

Aller plus loin

  • # C'est triste !

    Posté par  (site web personnel) . Évalué à 8.

    C'est triste mais c'est la fin des trolls qui m'a occupé de nombreuses journées sur linuxfr :)

    http://about.me/straumat

    • [^] # Re: C'est triste !

      Posté par  . Évalué à 10.

      mais non c'est le début d'un nouveau genre de troll.

      Mono/.Net vs Java

      C'est ça aussi l'innovation

      • [^] # Re: C'est triste !

        Posté par  (site web personnel) . Évalué à 1.

        Troll pas vraiment neuf, avec un peu de brevet logiciel en plus :).

        • [^] # Re: C'est triste !

          Posté par  . Évalué à 9.

          Je pense qu'on peut proposer la loi suivante :

          "Quand un troll construit sur le modèle "Xsapucépalibre" s'effondre parce que X devient libre ou X disparait, un nouveau troll "Ysapucépablibre" prend sa place dans l'année qui suit".

          De nombreux corrolaires peuvent être imaginés. Notemment en terme de récursivité : KDEsapucépalibre alors que Gnome c'est libre pourrait très bien devenir "Gnomesacucépluslibre alors que KDE maintenant c'est libre".

          Mais je dois dire que la fin du "javasapucépablibre", ça me fout pas mal les boules. Il va falloir trouver une autre excuse pour dire que "javaçapu". Au moins, s'ils l'avaient mis sous licence BSD, on aurait pu dire "javaçapucétroplibre", maigre consolation.

          • [^] # Re: loi du troll

            Posté par  . Évalué à -3.

            "Quand un troll construit sur le modèle "Xsapucépalibre" s'effondre parce que X devient libre ou X disparait, un nouveau troll "Ysapucépablibre" prend sa place dans l'année qui suit".

            je dirais plutot
            "e^Y sapucépalibre" car l'année suivante les trolleurs font dans la surenchère de façon exponentielle

          • [^] # Re: C'est triste !

            Posté par  (Mastodon) . Évalué à -3.

            sapulelangagépouri ?
            sapulalibébordélique ?
            sapucétroplan ?

            Il faut faire confiance aux habitants de ce site, voyons. C'est pas du troll industriel, ça, madame, c'est du troll dans son habitat naturel. C'est vif, c'est en bonne santé, ça, madame.

            • [^] # Re: C'est triste !

              Posté par  (site web personnel) . Évalué à -3.

              pitonsémieu

              • [^] # Re: C'est triste !

                Posté par  (site web personnel) . Évalué à 1.

                Tu m'expliques comment tu met python ans une sandbox ? Des plugins python dans un navigatuer web de manière sécurisée ?

                A part pypy qui n'est pas vraiment une solution, je ne vois pas.

                • [^] # Re: C'est triste !

                  Posté par  (site web personnel) . Évalué à 3.

                  waw, super, c'est une réponse au même niveau que mon commentaire :)

                  Alors pour continuer, tu m'expliques comment tu scriptes blender et gimp avec java ?

                  Allez, y a pas des rubystes dans l'assemblée pour prendre le relai ?

          • [^] # Re: C'est triste !

            Posté par  (site web personnel) . Évalué à -1.

            En même temps, on peut toujours dire : "javaçapucépaassezlibre".

            Rien ne vaut une bonne licence BSD !

            Et puis, GPL ou BSD, ça prend toujours autant de RAM :-(

            • [^] # Re: C'est triste !

              Posté par  . Évalué à 1.

              Ah bah oui mais là on attaque dans l'argument concret, quand le troll sent trop le savon, il n'attire plus les mouches...

          • [^] # Re: C'est triste !

            Posté par  (site web personnel) . Évalué à 7.

            > Il va falloir trouver une autre excuse pour dire que "javaçapu".

            Rassure toi, il reste toujours "Javaçaylourégourman_enressources" pour justifier ;D

            There is no spoon...

      • [^] # Re: C'est triste !

        Posté par  . Évalué à 10.

        bien au contraire: ce troll vient d'être réduit au silence...
        un silence si épais qu'on entend les chaises voler.

      • [^] # Re: C'est triste !

        Posté par  (site web personnel, Mastodon) . Évalué à -5.

        Mono et Java sapuesaypalibrebreveté.
        Python ça roxe c'est libre !

        • [^] # Re: C'est triste !

          Posté par  (site web personnel) . Évalué à -1.

          Et tu es sûr que Python ne viole aucun brevet ???
          En tout cas, avec Java, on est relativement protégé

          http://about.me/straumat

          • [^] # Re: C'est triste !

            Posté par  (site web personnel) . Évalué à 4.

            En tout cas, avec Java, on est relativement protégé

            Ah, Microsoft a passé avec Sun un accord de non-agression avec contreparties financières?

            [toute ressemblance avec un accord récemment passé serait tout à fait fortuit]

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

            • [^] # Re: C'est triste !

              Posté par  (site web personnel) . Évalué à 10.

              http://www.sun.com/smi/Press/sunflash/2004-04/sunflash.20040(...)


              Future Collaboration for Java and .NET: Sun and Microsoft have agreed that they will work together to improve technical collaboration between their Java and .NET technologies.

              Patents and Intellectual Property: The parties have agreed to a broad covenant not to sue with respect to all past patent infringement claims they may have against each other. The agreement also provides for potential future extensions of this type of covenant. The two companies have also agreed to embark on negotiations for a patent cross-license agreement between them.

          • [^] # Re: C'est triste !

            Posté par  (site web personnel) . Évalué à 7.

            Relativement alors.

            Est ce qu'il est protégé des brevets kodak ?
            http://wiki.ffii.org/SunKodak04En

            Est ce qu'il est protégé des brevets triviaux (un objet qui interagit avec un autre dans le but de [votre clause ici]) ?

            Sans compter que java ne fait pas partie du périmètre défendu par l'OIN contrairement à python ou mono.


            Bref, je ne me sentirait pas vraiment plus protégé avec java que python (et encore moins avec mono, même si cette remarque risque de m'attirer les foudres d'un grand amateur de calculatrices graphiques).

    • [^] # Re: C'est triste !

      Posté par  . Évalué à -1.

      Ne t'en fais pas, il reste quand même le principal sujet de troll.
      Car si java devient libre, ça ne change malheureusement rien au fait qu'il est extrêmement lourd !

      • [^] # Re: C'est triste !

        Posté par  . Évalué à 2.

        Sauf que si il est libre et que la politique des mainteneurs est ouverte à l'égard des patches, on va voir fleurir assez vite des améliorations...

        • [^] # Re: C'est triste !

          Posté par  . Évalué à -4.

          Ce qu'il vient de dire reste valide alors.
          Sous licence BSD on aurrait au moins eue du code de qualité.

        • [^] # Re: C'est triste !

          Posté par  . Évalué à 10.

          Sauf que si il est libre et que la politique des mainteneurs est ouverte à l'égard des patches, on va voir fleurir assez vite des améliorations...

          C'est vrai, d'ailleurs depuis qu'OpenOffice est libre, il est devenu très léger.

  • # Ok...

    Posté par  . Évalué à 0.

    Plutot content meme si il faut rester vigilant et que j aurai préféré ce type de framework vienne vraiment de la communauté et non d une entreprise enfin ne boudons pas notre plaisir ...
    Une question : Sera enfin il possible de porter à terme des versions pour les plateformes non supportés officiellement voire carrément pas ??

    • [^] # Re: Ok...

      Posté par  (site web personnel) . Évalué à 8.

      Perso, je ne vois pas de "différence"... Java a été développé de manière assez "collaborative" (avec Apache, Jboss, IBM, Oracle..). Ce qui compte, c'est le résultat. Je ne vois pas ce que ça change de savoir qu'Open Office vient d'une société ou d'une communauté, ça n'enlève pas les qualités du projet

      Pourrais tu préciser ta deuxième question ? je suis pas sur de comprendre.
      Pour info, du code 1.4 compile et tourne très bien sur une JVM 1.5

      http://about.me/straumat

      • [^] # Re: Ok...

        Posté par  . Évalué à 6.

        je pense que le monsieur parlait de plateforme materielle.

      • [^] # Re: Ok...

        Posté par  . Évalué à 4.

        Pour info, du code 1.4 compile et tourne très bien sur une JVM 1.5


        C'est faux : tout ne passe pas, exemple ici.


        Enumeration enum = monObjet.getEnumeration();


        Le nom 'enum' est un mot clé réservé de java 1.5, ceci compile donc en 1.4 et pas en 1.5.
        Je pense qu'il y a d'autres exemples, mais je n'ai encore jamais travaillé avec java 1.5, désolé.

        • [^] # Re: Ok...

          Posté par  (site web personnel) . Évalué à 1.

          Tu veux dire que dans ton code 1.4, tu as crée une classe Enumeration ? ok, c'est vrai, je n'y avais pas pensé.
          Néanmoins, dans toutes les applis que ma société a développé, on a jamais eu de prbs pour passer à java 1.5... On s'en rend même pas compte !

          http://about.me/straumat

          • [^] # Re: Ok...

            Posté par  (site web personnel) . Évalué à 5.

            En même temps ca peut être un mot clé du langage mais pas de la VM, auquel cas du code déjà "compilé" en bytecode en 1.4 peut tourner sur 1.5. Quand à ceux qui ont un problème à la compilation, c'est qu'ils ont les sources pour faire la modif ;)
            (Ca reste à vérifier)

          • [^] # Re: Ok...

            Posté par  . Évalué à 3.

            non, enum est un mot cle en 1.5 mais ne l'est pas en 1.4.

            ie : ce code compile avec un javac 1.4.x ou anterieur, mais pas avec un 1.5 qui t'envoie boulet car enum n'est pas accepte en tant que variable.

            Eclipse previent de ce genre de chose quand on developpe en 1.4, FYI.

            L'interface Enumeration est dans java depuis la version 1.0, FYI aussi.

            • [^] # Re: Ok...

              Posté par  . Évalué à 6.

              ce code compile avec un javac 1.4.x ou anterieur, mais pas avec un 1.5

              Ça n'est pas tout à fait vrai : tu peux compiler ce code avec le compilo du JDK 1.5, si tu passes le paramètre "-source 1.4".

    • [^] # Re: Ok...

      Posté par  (site web personnel) . Évalué à 10.

      Une remarque: SUN libère l'ensemble de SON implémentation de Java, mais les specs déjà sont libres (http://jcp.org/en/home/index) et réalisées dans un cadre de participation ouverte.

      Le fait que sa machine est libéré en GPL est un pas intéressant, mais en même temps rien n'empechait une société de faire son compilateur ou sa machine virtuelle (si: l'argent et le temps).

      • [^] # Re: Ok...

        Posté par  . Évalué à -2.

        est-ce le fameux "y'a qu'à" dont tu parles ?

        si c'était si facile GJC nous permettrait depuis longtemps de nous passer d'une machine virtuelle.

        • [^] # Re: Ok...

          Posté par  (site web personnel) . Évalué à 1.

          beh oui... il y a qu'à... bea a fait la sienne !

          http://about.me/straumat

          • [^] # Re: Ok...

            Posté par  . Évalué à 2.

            Et le moins que l'on puisse dire, c'est que la jrockit est plutot performante. Certes des fois moins stable par défaut qu'une sun, mais en général plus performante. En tout cas c'est ce que j'ai pu tester sur différentes applications avec l'outil LoadRunner. Bon tout ça est proprio mais on fait le métier qu'on peu ;-)

        • [^] # Re: Ok...

          Posté par  . Évalué à 3.

          A ce propos
          http://www.lemondeinformatique.fr/actualites/lire-java-open-(...)

        • [^] # Re: Ok...

          Posté par  . Évalué à 3.

          toujours pas compris l'interet de gcj pour un langage dont l'une des caracteristiques et atout majeur est justement le byte code...

          Un peu comme si quelqu'un faisait une VM pour executer du code c++ compile...

          • [^] # Re: Ok...

            Posté par  . Évalué à 6.

            >Un peu comme si quelqu'un faisait une VM pour executer du code
            >c++ compile...

            http://llvm.org ?

            (compilé certes mais pas en natif, plus toute les possibilités d'optimisations à l'exécution)

      • [^] # Re: Ok...

        Posté par  . Évalué à 2.

        mais les specs déjà sont libres

        Les specs sont peut être déjà libre mais seul Sun (et son réseau de partenaires : IBM, SAP, Apache, Jboss, ...) pouvait implémenté de nouvelles fonctionnalité à Java.

        Un JSR (Java Specification Request) doit obligatoirement :
        - implémenter complétement les spécifications,
        - ne pas ajouter ni supprimer no modifier quelque choses dans les packages définis par la spécification
        - passer les tests de compatibilité

        • [^] # Re: Ok...

          Posté par  . Évalué à 3.

          tu veux donc dire que que les développeurs du libres sont incapables d'implémenter correctement et complétement des specs ?

          • [^] # Re: Ok...

            Posté par  (Mastodon) . Évalué à 4.

            Je crois qu'il veut dire que si tu ajoutais un truc à Java, tu ne pouvais plus l'appeler "Java". Je ne pense pas que ça va changer avec la libération du code source, d'ailleurs.

            • [^] # Re: Ok...

              Posté par  . Évalué à 3.

              si on s'en refere a l'article de boubou, en fait une fois la certif Java obtenue, tu peux diverger de la specif officielle.

              Par contre t'as pas le droit de diffuser avant d'avoir eu la certif, et du coup c'est relativement incompatible avec un developpement ouvert.

              toujours selon ce meme article (et non, pas lu la mise a jour parue recemment, les linux mag sont trop cher pour moi, desole)

              'fin c'est pas comme si sun avait deja emmerde un projet java open source.

        • [^] # Re: Ok...

          Posté par  (site web personnel) . Évalué à 5.

          > Les specs sont peut être déjà libre mais seul Sun (et son réseau de partenaires : IBM, SAP, Apache, Jboss, ...) pouvait implémenté de nouvelles fonctionnalité à Java.

          Ou est le problème ???

          De la meme manière qu'il y a des spécifications pour le C, le C++, Python, Perl, etc...

          Dans tous les projets sans exception il y a un groupe, un comité qui décide de l'évolution du projet.
          Dans le cas de Java en quoi ça t'interdit de créer des nouvelles classes ? en quoi ça t'interdit de forker les specs de la JVM, a part le fait de ne plus appeler ça Java ?


          Faut arreter d'être ridicule !

          • [^] # Re: Ok...

            Posté par  . Évalué à 2.

            Ou est le problème ???

            - On réduit l'inovation possible à un groupe d'entreprise.
            - Toute diffusion d'une version incomplète d'une JSR ou qui ne passe pas le test (TCK) est potentiellement illegale.
            - Toute publication d'une implémentation libre qui ne passe pas le TCK est donc interdite.

            L'analyse de RMS : http://www.gnu.org/philosophy/java-trap.html

            Pour le passage en licence GPL change quand même pas mal le problème.

            De la meme manière qu'il y a des spécifications pour le C, le C++, Python, Perl, etc...

            Des spécifications qu'on peut "forker" sans tomber dans l'illégalité.

            Dans tous les projets sans exception il y a un groupe, un comité qui décide de l'évolution du projet.

            C'est une "vérité vrai". ;-)

            Dans le cas de Java en quoi ça t'interdit de créer des nouvelles classes ?

            Rien ne te l'interdit quand tu ne l'implémentes pas dans "java".

            en quoi ça t'interdit de forker les specs de la JVM, a part le fait de ne plus appeler ça Java ?


            Toute implémentation d'un JSR risque de violer des brevets des brevets, il faut donc obtenir une licence (contenu dans celle ou on accepte les spécifications).

            Sun possède actuellement 90 brevets mentionnant java mais (contrairement à .NET), il est clairement spécifié qu'il est permis réaliser une implémentation (qui respecte le JSR).


            Mais maintenant que Java est libre, JE dis "merci beaucoup" SUN et bravo ! (car même avant je ne crachait pas du tout sur JAVA, ... bien au contraire)

            PS : J'ai longement hésiter avant de parler au présent :-D

            • [^] # Re: Ok...

              Posté par  . Évalué à 5.

              c'est pas tout a fait vrai.
              Si tu implémente un compilo qui comprend des tas de trucs , mais qui implémente que la moitié de la norme c++, faut etre de mauvaise foi pour l'appeler 'compilo c++' (mais ca arrive).

              ensuite rien n'interdis de créer de nouvelles classes/API... du moment qu'elle ne soit pas dans java. mais par exemple gnu. .

              De toute facon , classiquement, il est inintéressant de modifier le langage en lui même , pour de simple raison de portabilité de code. Si tu veux modifier le langage, il faut mieux alors le forker.

              Enfin cela a été établis non pas pour etre méchant avec la communauté du libre (je crois que sun a plus grand chose a prouver de ce coté la), mais bel et bien pour empecher ms d'implémenter une vm et/ou un compilo pas totalement compatible pour tuer ce langage. Et ma foi ils ont eu gain de cause vu que ms a bien essayer de le faire, mais n'a pas pu l'appeler jvm.

    • [^] # Re: Ok...

      Posté par  . Évalué à 0.

      J avoue avoir du mal à comprendre mon moinssage j ai dit une connerie grosse comme le monde ??

      Teuz a bien compris c est effectivement de plateforme matérielle dont je parlais voilà ...

      • [^] # Re: Ok...

        Posté par  . Évalué à 5.

        Si moinssage il y a eu, c'est certainement pour la partie "j'aurais préféré que ça ne vienne pas d'une vilaine entreprise capitaliste impérialiste exploitatrice du peuple".

    • [^] # Re: Ok...

      Posté par  . Évalué à -6.

      Je constate que les seuls projets viables sont ceux soutenus par des sociétés et/ou par des chercheurs car ceux-ci applique de bonnes méthodes de dévellopement logiciel à leur projets à contrario des projets 100% communautaires où tt le monde peut coder avec ses habitudes.
      En devellopement logiciel l'important n'est pas le code mais l'architecture que l'on a pensé dés le début du projet avant de commençer à taper du code bêtement.
      Le cycle en V c pas pour les chiens.

      • [^] # Re: Ok...

        Posté par  (site web personnel) . Évalué à 10.

        Le cycle en V est une méthode qui ne fonctionne que lorsque l'on fait une boite noire où tous les signaux entrants et sortants sont parfaitement définis. Mais quand une interface dépend d'un humain, l'expérience montre que ça conduit à bien des déboires. La cause, elle est simple : Le cycle en V permet de vérifier que le produit livré est conforme aux spécifications mais il n'existe aucune méthode pour vérifier que les spécifications correspondaient aux besoins qui ont la fâcheuse manie d'évoluer. De plus il n'existe aucune méthode pour spécifier la faculté d'adaptation aux évolutions du logiciel après réception. Parfois, il faut tout refaire.
        Les normes de Qualité sont issues du monde du hardware où l'on ne doit faire que ce qui est strictement défini. Elles s'appliquent bien au logiciel embarqué mais très mal quand ce n'est pas le cas.

        Le cycle en V présume que les spécifications sont exactes et exhaustives, ce n'est jamais le cas quand un humain interfère avec le logiciel.

        • [^] # Re: Ok...

          Posté par  . Évalué à 1.

          Comme alternative au cycle en V, il y a Extreme Programming.

          Eclipse-Java-ExtremeProgramming, ça fonctionne très bien.

    • [^] # Re: Ok...

      Posté par  . Évalué à 9.

      dev_nexen a dit : Plutot content meme si il faut rester vigilant et que j aurai préféré ce type de framework vienne vraiment de la communauté et non d une entreprise enfin ne boudons pas notre plaisir...

      Ca changerait quoi? Parce que j'ai l'impression que pas mal de gens font encore le maladroit amalgamme entre GPL et "développeurs contributeurs depuis chez eux" et "gratuité". L'argent n'est pas sale, et les entreprises jouent un rôle majeur dans la promotion des logiciels libres. A l'heure où l'industrie mondiale en est rendue à externaliser et sous-traiter la moindre de ses activités, l'intégration, le support et la maintenance informatique sur les logiciels libres sont un aspect essentiel à comprendre qui définira le futur succès des logiciels libres.

      • [^] # Re: Ok...

        Posté par  (site web personnel) . Évalué à 1.

        Tout à fait d'accord. Ce n'est pas important de savoir qui fait un logiciel libre. L'important est de savoir quelle est la licence et que vaut le logiciel et sa communauté. Qu'il soit maintenu par un groupe de boites ou un groupe d'individus ou un mix des deux, peu importe (à part le fait que ça donne un indice sur le soutien).

        Les entreprises, ce n'est pas forcément le mal absolu. On a le droit de gagner de l'argent avec les logiciels libres. Je suis fier de savoir que les développeurs que je paye peuvent développer du logiciel libre et je ne vais pas m'excuser du fait que l'on gagne de l'argent !

        http://about.me/straumat

        • [^] # Re: Ok...

          Posté par  . Évalué à -1.

          C est pas vraiment à cause de ça, c est plus au fait que tout les morceaux de Java n appartiennent pas forcément à Sun, les brevets éventuels/supposés qui pésent dessus ... Mais c est tout de meme une bonne nouvelle ce passage à la GPL c est pas come si j avais dit Javaçapumachinchose... Ici plus ça va, plus t as intéret à avoir un avis polissé et qui rentre dans le moule pour etre plussé ... Ciao

          • [^] # Re: Ok...

            Posté par  . Évalué à 2.

            Ici plus ça va, plus t as intéret à avoir un avis polissé et qui rentre dans le moule pour etre plussé
            En soi, être plussé ne doit pas devenir un but, même si je reconnais que c'est vexant de voir un commentaire sincère se retrouver dans le négatif. Sinon, on n'en est (heureusement) pas encore rendu à mettre des disclaimers partout, mais pour revenir à ton commentaire et ma réponse précédents, il y a une certaine tournure d'esprit qui correspond à chaque licence et ton commentaire moinssé prenait la GPL à rebrousse-poil tout en se réclamant de la GPL. Il ne faut pas chercher plus loin. Les trolls sur Javaçapue, peu de monde (je crois) les prend encore au sérieux...

            tout les morceaux de Java n appartiennent pas forcément à Sun, les brevets éventuels/supposés qui pésent dessus
            Là-dessus, je ne crois pas qu'il y ait de souci à se faire. En modèle propriétaire, Sun défendait son beefsteak sur les aspect "brevets". En franchissant le cap du changement de licence, ils ont dû investir pas mal de temps (donc d'argent) dans l'inventaire des propriétés intellectuelles et l'audit du code source pour éviter des déboires juridiques et éventuellement négocier la libération de morceaux propriétaires avec leurs ayant-droit. Enfin, si un auteur se juge lésé de sa propriété intellectuelle à travers l'ouverture de Java, il se retournera contre Sun et celui-ci ou la communauté auront la possibilité de recréer les fonctionnalités pointées du doigt.

            • [^] # Re: Ok...

              Posté par  . Évalué à 1.

              Les trolls sur Javaçapue, peu de monde (je crois) les prend encore au sérieux...
              Dis ca a mon ordi qui a pas forcément bcp de mémoire :( :( :( java seul ca va, mais une appli java + fx + icedove(thunderbird) je suis pas loin de la swap :(
              (rem c'est pas que la faute de java ;))

  • # un rêve ?

    Posté par  (site web personnel) . Évalué à -3.

    Le titre est ambigü... qu'une grosse boite libère un de ses projets monstres, c'est génial... mais bon perso, coder en Java même libre c'est plus un cauchemard qu'un rêve :P

    • [^] # Re: un rêve ?

      Posté par  . Évalué à 4.

      Ah bon...

      Et peux-tu argumenter s'il te plaît ?

      En quoi coder en java est-il un cauchemar ?

      Le language ? J2SE ? Les outils ? Les frameworks ? Les performances ?

      Quel language utilises-tu ?

      • [^] # Re: un rêve ?

        Posté par  . Évalué à 1.

        Cherche pas, on reconnait les trolls à 2 kms à la longue.
        Celui là il a des écailles et la langue fourchue et son tour de taille fait pi au carré.

      • [^] # Re: un rêve ?

        Posté par  (site web personnel) . Évalué à 0.

        Et peux-tu argumenter s'il te plaît ?

        Ben non surtout pas, sinon on tombe vraiment dans le troll...
        Chacun trouvera ses propres réponses à tes questions :)

        • [^] # Re: un rêve ?

          Posté par  (site web personnel) . Évalué à 0.

          Je crois que tu n'as pas bien compris ce qu'était un troll ...

          • [^] # Re: un rêve ?

            Posté par  (site web personnel) . Évalué à 1.

            Un troll, c'est pas un gros thread plein d'arguments subjectifs ou mal compris par les participants ?

            En l'occurence sur les langages c'est les goûts et les couleurs, surtout ici où on doit pouvoir trouver des fans de moults paradigmes de programmation, des débutants, des hackers, des industriels et des académiques... Donc je sais pas pourquoi, je m'attends au pire si j'essaye d'argumenter :-)

            Je préfère les remarques sibyllines mais qui peuvent prêter à réflexion, na.

  • # C'est bien

    Posté par  (site web personnel) . Évalué à 10.

    Oui, c'est vraiment bien. Sun mérite les lauriers du libre.

    La révolution du libre continue de faire son chemin.

    Qt libéré, Netscape libéré, StarOffice libéré et maintenant Java, libéré. Que de chemin parcouru.

    Votre pronostic pour le suivant sur la liste ?

    • [^] # Re: C'est bien

      Posté par  . Évalué à 2.

      Je dirais même plus, c'est bien !

      A ce propos, sans vouloir polémiquer, il existe un binding GTK pour java :
      http://java-gnome.sourceforge.net/cgi-bin/bin/view

      Aussi, je trouve dommage que Gnome ait choisi de se rendre dépendant de Mono, alors que java permet d'écrire des applications parfaitements intégrées, et qu'apparemment, il y a moins d'incertitutudes juridiques avec java.

      • [^] # Re: C'est bien

        Posté par  (site web personnel) . Évalué à 4.

        Aussi, je trouve dommage que Gnome ait choisi de se rendre dépendant de Mono
        Gnome n'a rien choisi du tout. Les bindings pour Java sont dispos depuis longtemps et sont synchronisés depuis un moment avec les releases officielles de Gnome. Maintenant si Gnome a choisi une première appli Mono (Tomboy) et non Java, c'est plus parcque l'appli en question était dans l'esprit du projet. Si demain une appli Java intégrée à Gnome est susceptible de faire partie intégrante du projet, je suppose qu'ils n'hésiterons pas à le faire.

        • [^] # Re: C'est bien

          Posté par  . Évalué à 3.

          Pardon ?

          Et cette dépêche alors ?
          http://linuxfr.org/2006/09/07/21297.html

          Je cite :
          On notera au passage l'arrivée d'une application en C# (Tomboy), qui officialise la dépendance de GNOME sur Mono et sur le binding GTK#, ainsi que l'utilisation des nouvelles fonctionnalités offertes par GTK+ 2.10.


          Donc Gnome dépend maintenant de Mono, et c'est bien les responsables de Gnome qui l'ont choisi, j'imagine que personne ne leur a imposé ce choix.

          D'ailleurs, ça a suffisement trollé sur le sujet ce jour là pour que tout les lecteurs de DLFP s'en souviennent.

          • [^] # Re: C'est bien

            Posté par  (site web personnel) . Évalué à 4.

            Me suis mal exprimé. Ce que je voulais dire c'est que Gnome n'a pas choisi d'être dépendant de GTK#/Mono, elle a choisi d'utiliser Tomboy, et donc se retrouve dépendant de GTK#/Mono.
            Bref, tout ca pour dire que ils ont pas troller sur "On choisi Mono ou Java ?". Ils ont fait ca de manière plus pragmatique : ils ont choisi une application (en regardant quand même ses dépendances). Il se peut très bien qu'une appli Java fasse également son apparition si elle est cohérente avec le projet.

            • [^] # Re: C'est bien

              Posté par  (site web personnel) . Évalué à 4.

              Donc au final on va se retrouver avec x Mo de dépendances juste pour 2 applis... c'est beau !!!

              • [^] # Re: C'est bien

                Posté par  . Évalué à 3.

                d'un autre cote, si tu veux qqchose de leger, c'est pas gnome ni kde qu'il te faut, hein...

                et a moins que tu fasse fructifier tes octets inutilises en bourse, c'est pas les, soyons TRES larges, 50+mo de dependances en plus qui vont te plomber ton disque dur.

                • [^] # Re: C'est bien

                  Posté par  . Évalué à 1.

                  Sauf que mono a aussi ses dépendances, qui ont, elles aussi leurs dépendances, qui ont, ...

                  Et si chacun tient ce genre de raisonnement, l'ordre de grandeur sera plutôt le Go que le Mo. Et s'il faut lancer chaque petite appliquette dans une machine virtuelle différente, il faut aussi considérer la quantité de mémoire vive nécessaire.

                  • [^] # Re: C'est bien

                    Posté par  (site web personnel) . Évalué à 5.

                    Faut quand même bien voir qu'un des gros atouts des frameworks de type Java/Mono, c'est de proposer en "standard" un grand nombre de bibliothèque. Ok au départ y'a plus de trucs à installer (quoique, quand c'est bien découpés en packages...), mais après tous les softs dépendent généralement des mêmes libs. Tu prends un programme en C/C++, chacun y va de sa lib XML, chacun y va de son moteur de log, certain sont compilés en statique, d'autre en dynamique. Bref, ca peut vite grossir alors que grosso-modo une appli Mono/Java ne demandera pas grand chose de plus que le framework standard.

                    Et s'il faut lancer chaque petite appliquette dans une machine virtuelle différente, il faut aussi considérer la quantité de mémoire vive nécessaire.
                    Là c'est pareil : au "pire" y'a 2 environnements qui s'exécutent, Mono et Java. Après 2 applis Mono partagent les mêmes libs en mémoire s'il le faut. On va même retrouver de nombreuses libs en commun avec les appli natives : Qt, Gtk, Gnome, etc.

      • [^] # Re: C'est bien

        Posté par  . Évalué à 1.

        Aussi, je trouve dommage que Gnome ait choisi de se rendre dépendant de Mono


        Le jour où Gnome intégrera une appli Java, il se retrouvera dépendant de Java...

    • [^] # Re: C'est bien

      Posté par  . Évalué à 10.

      QT libéré sans doute à cause de GTK. Netscape pour ne pas disparaître définitivement face à IE, StarOffice pour espérer prendre des part de marché à MS Office, et Java sans doute un peu pour redonner un coup d'accélérateur face à .Net

      Il suffit de regarder quel est le prochain truc qui va être en concurrence avec le rouleau compresseur de Redmont. J'ai cru comprendre que Microsoft lançait un format pour concurrencer le PDF... Et il n'ont pas aussi un truc genre Flash dans les cartons ?

      • [^] # Re: C'est bien

        Posté par  (site web personnel) . Évalué à 3.

        >Microsoft lançait un format pour concurrencer le PDF...

        PDF, oui oui oui !

        Sinon, je suis assez d'accord avec ton analyse. Sinon que j'ajouterai que, de mon point de vue, toutes ces libérations "de survie" sont des réussites.

        • [^] # Re: C'est bien

          Posté par  . Évalué à 2.

          Ca serait bien que Acobat Reader devienne libre, je trouve que c un trés bon logiciel malgré sa lourdeur.
          Par contre dire que toutes "ses libérations de survie" ont été des réussites faut pas éxagerer :
          Firefox est lourd surement à cause de XULRunner (une vrai usine à gaz), à côté IE est rapide en tt cas de figure. Après pour la sécurité à l'utilisation je ne peut pas juger;
          OpenOffice est aussi lourd et loin d'arriver à la cheville de MS Office;

          pour ne citer que deux exemples.

          • [^] # Re: C'est bien

            Posté par  . Évalué à 4.

            J'utilise OOo et Firefox sous windows et sous Linux. Sous Windows je peux comparer les produits libres et les produits MS. Et bien crois moi, les produits libres n'ont pas à rougir.

            FF est beaucoup plus véloce que ie (mais que c lent ce truc...)
            Et OOo, depuis la 2.0, devient utilisable (je suis un peu dur là). Mais quand on voit que MS office se perd dès qu'un document fait plus de trois pages avec des styles un poil complexes... Bien qu'il ait bcp plus de fonctionnalités qu'OOo, et qu'il soit plus rapide, des fois j'utilise OOo car la gestion des styles est plus robuste (boite sous MS office, avec templates asez complexes, donc j'ai plutôt tendance à choisir MS office par défaut pour les documents "jolis" de travail).

            Pour résumer: les deux mondes ne sont pas parfaits, mais OOo et firefox sont vraiment de bon logiciels, meme si firefox est beucoup plus compétitif que OOo face à ses pairs MS.

      • [^] # Re: C'est bien

        Posté par  . Évalué à 5.

        Ça serait cool si NVIDIA et ATI faisaient de même en suivant Intel dans sa démarche d'ouverture :)

        • [^] # Re: C'est bien

          Posté par  (site web personnel) . Évalué à 1.

          Faudra attendre que les "nettoyage" dans la chaîne dirigeante du nouveau groupe ati+amd aient lieu pour faire remonter le court en baisse...

          Avec un peu de chance ce seront les abrutis de ati qui dégageront et ils commenceront peut-être a faire des drivers potables ouvert ;)

    • [^] # Re: C'est bien

      Posté par  . Évalué à -1.

      Mono ?

  • # C'est tout ce que ça vous inspire ?

    Posté par  . Évalué à 10.

    La plupart des commentaires que je lis au-dessus semblent sombrer dans le regret du troll disparu.

    C'est pourtant une barrière derrière laquelle il y a une grande richesse de projets qui vient de tomber. Même si nous (utilisateurs de LL) utilisions déjà largement java auparavant, cette annonce de Sun nous ouvre largement les portes d'une communauté très productive.

    Sans compter que nombre de projets libres écrits en java restaient timides car s'appuyant sur une machine virtuelle non libre. Maintenant, les ponts relient bien les deux rives, et les pisseurs de code java vont pouvoir vivre en harmonie avec ceux qui font la même chose en python, main dans la main, ensemble vers un monde meilleur (oops, je m'égare).

    Bref, vous l'avez compris, pour moi c'est champagne. Et on trouvera toujours des trolls à lancer !

    • [^] # Re: C'est tout ce que ça vous inspire ?

      Posté par  . Évalué à 1.

      champagne!!

      je ne peux pas me rappeler le nombre considérable de programmes gnome/java qui attendaient dans l'ombre parce que "javacapucepalibre", et toutes sortes de Limewire, d'intégration en suspens de java dans os X , de facilité pour avoir le runtime dans ubuntu ou fedora , etc etc

      oui, ca va être grand! déjà, qu'on me foute java-gnome de base dans tous les linux, vite, vite !

      • [^] # Re: C'est tout ce que ça vous inspire ?

        Posté par  . Évalué à 7.

        Java, à la limite je veux bien. Mais Gnome alors non !

        • [^] # Re: C'est tout ce que ça vous inspire ?

          Posté par  . Évalué à 0.

          ne faites pas l'esprit chagrin

          évidemment, il faut lire : "dans les linux qui utilisent gnome par défaut et fournissent les bindings officiels et qui proposent des outils de développement java ou une application de qualité, basé gnome en java"

          voilà ? c'est mieux ?

    • [^] # Re: C'est tout ce que ça vous inspire ?

      Posté par  (site web personnel) . Évalué à 3.

      Ca me rappelle il y a 5 ans où j'avais créer un projet GPL pour intercepter des communications Corba, le tout en Java.
      J'avais proposé le projet à Savannah, pour être dans les projets GNU, et on m'avait gentillement fait comprendre que tant que mon projet ne marchait que sur une JVM non libre, il ne serait pas accepté. Résultat : direction sourceforge.
      Avec le changement en GPL de la JVM Sun, j'imagine que les liens FSF <-> Java seront plus simples.

      Je suis impatient de voir la réaction officielle de la FSF et de Richard Stallman vis à vis de cette libération.

  • # Bof

    Posté par  . Évalué à -9.

    deux choses :
    - C'est tout ce que Sun trouve pour faire parler d'eux ? Eh ben, ... !
    - Ca ne me donne pas plus envie de me mettre au java. Pour moi java c'est synonyme de "matraquage publicitaire a outrance de la part de commerciaux" ... exactement comme .net d'ailleurs.

    On veut a tout pris me les fourrer dans les mains... j'aime pas.

    • [^] # Re: Bof

      Posté par  (site web personnel) . Évalué à 8.

      Libérer une plateforme aussi répandu que Java est un truc énorme. Et c'est normal qu'on en parle. Ne sois pas de mauvaise foi.

      tu as le droit de pas aimer et de ne pas t'y mettre. Perso, un mec qui vient poster sur une news java pour dire qu'il aime pas Java, je trouve ça d'un con.

      Quand au coté publicitaire... si tu veux mais il y a quand même des produits Java géniaux que tu trouves pas partout ! (JTA, Maven, Ant, Spring, GWT, Hibernate....)
      Tu peux croire que c de la publicité mais viens travailler chez nous et tu verras les merveilles que ça fait ! et je peux te dire que les langages qu'on faisait ne lui arrivaient pas à la cheville (Delphi, PHP...)

      http://about.me/straumat

    • [^] # Re: Bof

      Posté par  . Évalué à 7.

      Pour ma part, Java étant très présent en entreprise (quelle grosse entreprise ne l'utilise pas ?)

      C'est donc faire entrer la GPL par la grande porte.

      Avec cette nouvelle, la GPL est maintenant utilisée par de nombreuses entreprise sur des gros projets.

  • # Et les autres projets ?

    Posté par  (site web personnel) . Évalué à 10.

    Java en GPL, c'est bien, mais quelle conséquence pour les projets de "remplacement" ?

    Je pense à en particulier à GCJ, Kaffe, SableVM, etc.

    Ces projets ont été lancés pour avoir une machine virtuelle Java libre (pas de VM pour GCK, oui.). Si la JVM de Sun devient libre, quel avenir pour ces projets ?

    • [^] # Re: Et les autres projets ?

      Posté par  . Évalué à 8.

      Je n'ai pas de boule de cristal mais je suis convaincu qu'ils n'auront pas servi à rien.

      Sans ces implémentations libres, SUN n'aurait peut-être toujours pas pris la décision de libérer java.

      Espérons que ces projets évolueront et utiliseront le meilleur du code disponible, puisqu'ils ont maintenant la possibilité d'en intégrer tout ou partie.

      • [^] # Re: Et les autres projets ?

        Posté par  . Évalué à 3.

        Outre la "pression" maintenue grâce à ces implémentations, Sun va pouvoir intégrer du code de GCJ dans le sien. Bon après, GCJ est en C, la JVM de Sun en Java et/ou C++ si je ne m'abuse, et vu le niveau de finition de GCJ ca vaut peut être pas le coup ...

        • [^] # Re: Et les autres projets ?

          Posté par  (site web personnel) . Évalué à 3.

          Sun va pouvoir intégrer du code de GCJ dans le sien.
          Sun va pouvoir le faire, mais quelque chose me dit qu'ils ne vont "surtout" pas le faire. Pour garder le copyright intégral de leur plateforme, et donc pouvoir la licencier comme ils l'entendent pour satisfaire tout type de client.
          Par contre l'inverse sera plus probable, l'implémentation de Sun permettra de combler les trous de GNUClassPath par exemple (pour la partie bibliothèque).

          • [^] # Classpath

            Posté par  (site web personnel) . Évalué à 3.

            Voici une position d'un des mecs du projet Classpath :
            http://kennke.org/blog/?p=25


            Extrait :
            "the fact is that now there is really no hard need for the GNU Classpath project anymore. But I want to raise two aspects here:
            1. Many projects are built around GNU Classpath right now. It won’t be exactly easy and trivial to port them over to Sun’s libraries.
            2. The development environment of GNU Classpath is much more flexible right now. This spirit of hack - test - commit is part of what makes GNU Classpath attractive for developers, including me.

            So, I think both codebases will peacefully coexist for a while, and most likely converge too quite a great degree. If at a later point they merge into one or if they will continue to coexist, time will tell."

            Faut pas rêver, je pense. Le projet Classpath a fait beaucoup de bien au logiciel libre pour inclure des softs comme Eclipse dans les distribs actuelles. Mais maintenant, ca va être chaud de trouver des gens motivés pour continuer à le faire évoluer sachant qu'il sera toujours en retard de version vis à vis du JDK Sun.

      • [^] # Re: Et les autres projets ?

        Posté par  . Évalué à 4.

        Sans ces implémentations libres, SUN n'aurait peut-être toujours pas pris la décision de libérer java.

        J'ai même l'impression que Sun libère quelque chose dès qu'il y a une alternative libre viable. Pour le moment, ils vont passer la JVM et 2-3 gadgets sous GPL, mais bon des JVM libres on en a déjà des caisses. Pour ce qui est de la bibliothèque de classe (c'est un peu ce que tout le monde attendait) c'est pour plus tard (l'an prochain). Comme par hasard c'est lorsque ClassPath commence à être bien fourni qu'ils envisagent de libérer leur bibliothèque ? En gros le temps qu'il libèrent leur bousin on n'en aura plus besoin.

      • [^] # Re: Et les autres projets ?

        Posté par  (site web personnel) . Évalué à 6.

        >Sans ces implémentations libres, SUN n'aurait peut-être toujours pas pris la décision de libérer java.

        C'est l'histoire de Qt, de KDE et de quelques "intégristes" qui disent non et qui fondent Gnome. Résultat : aujourd'hui, il existe 2 environnement de bureau libres et c'est la richesse de l'offre logicielle et la liberté du l'utilisateur qui en est renforcé.

      • [^] # Re: Et les autres projets ?

        Posté par  . Évalué à 5.

        Je n'ai pas de boule de cristal mais je suis convaincu qu'ils n'auront pas servi à rien.

        Oui, et une autre raison qu'on peut évoquer, c'est qu'ils auront servit à former plein de spécialistes pointus qui connaissent parfaitement les JVM, qui ont peut-être eu des meilleures idées que Sun sur certains points (pour avoir approché les mêmes questions d'une façon différente / dans une culture "informatique/entreprise" différente etc.).

        Bref ces projets auront aussi constitué un laboratoire d'idées neuves et un vivier de talents autour du coeur de java, dans le monde du libre. Si ces gens se mettent à contribuer à l'implémentation de Sun, celle-ci va sans doute faite un grand bon en avant. Les audits de patches seront surement meilleurs aussi (avec plus de gens qualifiés pour les relire, des gens ayant eu une expérience différente de l'implémentation de java, et venant d'horizon différents).

    • [^] # Re: Et les autres projets ?

      Posté par  (site web personnel) . Évalué à 3.

      Cela ne veut pas dire que toutes les autres machines vont disparaîtres. Certaines sont prévus dans une optique de portabilité, d'autres pour l'éducation, d'autres pour des environnement contraints (typiquement: de l'embarqué), d'autres ont l'avantage de profiter d'un environnement (GCJ permet par exempelde compiler du java en code binaire natif en utilisation la chaîne de compilation gcc).

      Au contraire, les autres implémentations vont continuer à travailler leurs "niches" de marché. Pour éviter les ennuis de la monoculture et offrir lechoix aux utilisateurs / intégrateurs.

      • [^] # Re: Et les autres projets ?

        Posté par  . Évalué à 10.

        Et de toutes façon, tu as déjà vu un projet GNU disparaître ? C'est pire que les sacs plastiques dans la nature, faut des dizaines et des dizaines d'années, le temps que les derniers utilisateurs/geeks qui sont liés au projet soient morts

        • [^] # Re: Et les autres projets ?

          Posté par  . Évalué à -2.

          oui, le Hurd.

        • [^] # Re: Et les autres projets ?

          Posté par  . Évalué à 2.

          Un projet GNU disparait rarement. Par contre, ça dépérit, faute de contributeur. Il me semble, lorsque je regarde sur sourceforge par exemple, que ce type de projet est légion. Et pour moi, il faut bien plus d'un contributeur pour que le projet vive (ou alors un bien motivé). Et les utilisateurs ne sont que rarement des contributeurs potentiels (en code).
          Malheureusement, je ne partage pas ton optimisme...

    • [^] # Re: Et les autres projets ?

      Posté par  (Mastodon) . Évalué à 5.

      Pour GCJ en tout cas, un des buts était d'avoir un compilateur Java vers du code natif, et pas vers du bytecode. Et de plus, intégré à GCC, ce qui permet à priori de gérer toutes les plateformes pour lesquelles il existe un backend GCC.

      Ensuite, avoir plusieurs VM, c'est bien, ça permet d'expérimenter des trucs. Ce qui bloquait surtout, ce n'étaient pas les VM mais les bibliothèques. Si j'ai bien compris, la libération des bibliothèques n'est pas pour tout de suite, ou bien est-ce inclus dans Hotspot ?

      • [^] # Re: Et les autres projets ?

        Posté par  . Évalué à 5.

        Non, ce n'est pas pour tout de suite. Pourtant c'est ça qu'on attend.

        La principale utilité de Java vient de Swing, Javasound...

      • [^] # Re: Et les autres projets ?

        Posté par  . Évalué à -3.

        Non, ce n'est pas pour tout de suite. Pourtant c'est ça qu'on attend.

        La principale utilité de Java vient de Swing, Javasound...

    • [^] # Re: Et les autres projets ?

      Posté par  . Évalué à 2.

      Je pense que c'est pour le mieux. C'est là selon moi une démultiplication des efforts pour parvenir rigoureusement au même résultat qui me parait totalement inutile et relativement vaine. Si cela peut permettre d'unir tous ces projets et d'améliorer ainsi la machine de Sun, on ne pourra que s'en réjouir. Évidemment, certains de ces projets ont peut-être quelques particularités qu'il faudrait conserver, peut-être que certains visent à porter une JVM sous un environnement peu utilisé et tout, mais si c'était juste pour avoir de la JVM et des bibliothèques libre, bref, la même chose que Sun mais en version libre, ces projets vont devenir à mon avis relativement inutiles.

  • # Java 6? Java 7?

    Posté par  . Évalué à 3.

    Pour ma part, j'en étais resté à Java 2.
    Merci de ne pas confondre le langage et ses implémentations (Java SE/ME/EE chez Sun).

    Sun sème déjà la confusion*, pas la peine d'en rajouter.

    *: La dernière version de J2SE disponible est connue comme la 1.5.0 ou la 5 tout court, au choix.
    Toute ressemblance avec le système de numérotation des versions de SunOS/Solaris du même éditeur...

    • [^] # Re: Java 6? Java 7?

      Posté par  . Évalué à 2.

      Justement, histoire de simplifier les noms, tout ce qui était J2 quelque chose perd son 2. Du coup, J2EE devient JEE, J2SE devient JSE,... le tout avec le nom de la version à la Sun, c'est à dire que ça sera désormais 5, 6, 7... la numérotation interne restant 1.x.
      Au final, ça devient plus clair et un peu moins compliqué à prononcer.

    • [^] # Re: Java 6? Java 7?

      Posté par  . Évalué à 6.

      en fait java2 representait la "renaissance" de java avec la version 1.2 (les version precedentes etaient assez chaotique)

      apres ya tout un micmac entre denomination technique et commerciale.

      Bref, depuis la version 1.5, c'est java5 java6 java7 etc.

      Donc en gros:
      * Java2 : java que tout le monde utilise a moins d'etre un brontosaure
      * Java 1.x : denomination technique
      * Java5/6/7 : denomination commerciale.

      ca a l'air un peu le bordel, mais quand t'y regardes bien pas tant que ca

      • [^] # Re: Java 6? Java 7?

        Posté par  . Évalué à 2.

        C'est vachement plus simple avec ces trois numérotations, ils ont raison !
        Peut-être une suggestion à faire aux développeurs d'autres grands projets ? Bientôt linux 2000 !
        Maintenant j'attends le jour où java va commencer à sauter des numéros de version majeure comme certaines distributions.

        • [^] # Re: Java 6? Java 7?

          Posté par  (site web personnel) . Évalué à 2.

          Il me semble que microsoft fait pareil avec ses versions de office et de windows. En tout cas, il l'a fait pour office. office 97=office 7 etc... j'ai arreté de compter depuis longtemps.

          • [^] # Re: Java 6? Java 7?

            Posté par  (site web personnel) . Évalué à 2.

            Je ne suis pas expert en MS Office, mais il me semble qu'il sont pire que Sun sur la numérotation...

            De mémoire...

            Office 4.2
            Office 95
            Office 2000
            Office XP
            Office 2003
            Office 12.0

            et j'en oublie surement !
            et je compte pas les déclinaison Pro, Premium, Small Business, Standard, PME...

            Un travail a temps plein. Je mets au défi de trouver un revendeur certifié Microsoft capable de vous réciter ce bréviaire !!

            • [^] # Re: Java 6? Java 7?

              Posté par  . Évalué à 2.

              Ou la première version de Windows NT : la 3.1

              ( remarquez la précision, 3.1, pour avoir un numéro de version identique à la version 16 bits, Windows « normal »)

            • [^] # Re: Java 6? Java 7?

              Posté par  . Évalué à 1.

              T'as oublié la Office 97 et puis tant que t'y est y a les versions macs :

              Office 98
              Office 2001
              Office v. X
              Office 2004

            • [^] # Re: Java 6? Java 7?

              Posté par  (site web personnel) . Évalué à 2.

              "Office 12.0"
              Ca c'est le numéro de version. Le nom commercial c'est Office 2007.

  • # Transcription des discours de RMS et Eben Moglen

    Posté par  (site web personnel) . Évalué à 6.

    http://guerby.org/blog/index.php/2006/11/13/127-great-news-for-free-software

    (pour les liens)

    Sun Microsystems has choosen the GNU General Public Licence to open its Java technology: see the official annoucement page.

    Here is my transcription of the small Richard Stallman video available on Sun site:

    It will be very good that the Java trap won't exist anymore, it will be a thing of the past. That kind of problem can still exist in other areas but it won't exist for Java anymore. The GNU General Public Licence is the most popular, most widely used free software licence. The special thing about this licence is that it's a copyleft licence, that is to say all versions of the program must carry the same licence so the freedoms that the GNU GPL gives to the users must reach all the users of the program and that's the purpose for which I wrote it. I think Sun has, well with this contribution, has contributed more than any other company to the free software community in the form of software. And it shows leadership, it's an example I hope other will follow.

    And here my transcription of the Eben Moglen video:

    As Java became one of the most important languages for the expression of ideas about technology of programming in the last decade the question of Java's freedom, wether it could be use freely and made part of free software projects, has been a crucial question. Sun's policy of GPL'ing Java, which we are celebrating now, is an extraordinary achievement in returning programming technology to that state of freely available knowledge. Sun has now GPL'ed hardware designs, Sun is GPL'ing Java: that's an extraordinary vote of confidence in this way of sharing information. And we, in the free software world, are very pleased and very flattered to see Sun taking its own very valuable and very important product and agreeing with us that they will be more advantageous to Sun as well as to the rest of the community if they are shared under these rules.

    Here is APRIL first reaction (french).

    • [^] # Traduction de la transcription

      Posté par  . Évalué à 5.

      Traduction (un peu torchée) de la transcription (pour ceux qui ne lisent pas du tout l'angliche) :
      Sun Microsystems a choisi la licence GNU GPL pour ouvrir sa technologie Java : voir la page de l'annonce officielle.

      Voici ma transcription de la petite vidéo de Richard Stallman disponible sur le site de Sun :

      Ce sera très bien que le piège de Java n'existe plus, que ce soit une chose du passé. Ce genre de problème peut encore exister à d'autres endroits, mais n'existera plus pour Java. La GNU General Public License est la licence de logiciel libre la plus populaire, la plus largement utilisée. Le point particulier à propos de cette licence, c'est que c'est une licence copyleft, c'est-à-dire que toutes les versions d'un programme doivent avoir la même licence, de façon à ce que les libertés que donne la licence GNU GPL aux utilisateurs atteignent tout les utilisateurs du programme, et c'est dans ce but que je l'ai écrite. Je pense que Sun a, notamment avec cette contribution, contribué plus qu'aucune autre compagnie à la communauté du logiciel libre sous forme de logiciel. Et cela montre la direction [NdT : un peu un faux sens, mais bon, y a rien de mieux qui me vienne maintenant], c'est un exemple que j'espère que d'autres vont suivre.

      Et voici ma transcription de la vidéo d'Eben Moglen :

      Comme Java est devenu l'un des langages les plus importants pour l'expression d'idées sur la technologie de programmation durant la dernière décennie, la question de la liberté de Java, c'est-à-dire s'il pourrait être utilisé librement et faire partie de projets libres, a été une question cruciale. La politique de Sun de rendre Java GPL, que nous célébrons maintenant, est une extraordinaire réalisation dans le retour de technologie de programmation à l'état de connaissance librement disponible. Sun a maintenant des conceptions matérielles GPL, Sun rend Java GPL : c'est un extraordinaire vote de confiance dans cette façon de partager de l'information. Et nous, dans le monde du logiciel libre, sommes très heureux et très flattés de voir Sun prendre ses propres produits si valables et si importants et s'accorder avec nous qu'il sera plus avantageux pour Sun aussi bien que pour le reste de la communauté qu'ils soient partagés suivant ces règles.

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # Nouvelles plate-formes supportées...

    Posté par  (site web personnel) . Évalué à 1.

    J'espère que ça va permettre l'apparition de Java sur certaines plate-formes qui n'en disposaient pas jusqu'ici...
    Je crois par exemple que le PocketPC n'en a toujours pas de potable (quoi que CrEme s'est amélioré il me semble...)
    et certains OS alternatifs !

  • # Application de la GPL

    Posté par  (Mastodon) . Évalué à 1.

    Un sujet n'a pas été abordé, mais pour moi, la GPL, au contraire de la LGPL, implique que tous les programmes liés au logiciel sous GPL héritent eux aussi de la même licence.

    Je suis un peu surpris. Je n'imagine pas que tous les logiciels écrit en java soient contraints de passer en GPL demain !

    Je suppose que Sun a pensé au problème :-) Je donc donc manquer quelque chose...

    Quelqu'un peut m'éclairer sur ce point qui me semble pour le moins important ?

    • [^] # Re: Application de la GPL

      Posté par  . Évalué à 2.

      En fait l'intégralité du code a été mis sous GPL avec l'exception ClassPath (du nom du projet GNU), qui autorise explicitement la liaison de la bibliothèque de classes avec n'importe quel autre code sous licence (pouvant être propriétaire).

      Il me semble d'ailleurs (à confirmer ?) que java sera toujours disponible sous licence propriétaire comme c'était le cas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.