Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
13
avr.
2004
Mozilla
Brendan Eich, architecte du projet Mozilla et inventeur de JavaScript, suite à la demande d'un contributeur, fait le point sur les priorités du développement de Mozilla.

D'après Brendan, concevoir un navigateur et une messagerie multi plate-forme libres et puissants n'est pas suffisant ; il faut voir plus loin, se préparer à contrer les technologies de Microsoft comme .Net et XAML (dans le cadre de Longhorn, prochaine version de Windows, prévue pour 2006). Pour cela, il faut mettre en commun les efforts, et présenter un front unifié et Libre basé sur des standards ouverts.

Avec l'existence de XUL (XML User-interface Language), déjà utilisé dans Mozilla, une alternative fiable à MS-XAML est disponible dès maintenant. XUL a déjà fait ses preuves dans Mozilla et dérivés (Firefox, Thunderbird, ...).

Reste à voir si Microsoft se laissera faire, ou si, au contraire, Mozilla subira le même sort que Netscape...

NdM : merci également à Nucleos pour l'info. Extraits de l'article de Brendan Eich : "Si nous ne nous préoccupons que du navigateur, nous risquons d'être mis hors course dans approximativement 5 ans. Non pas inutilisé, mais à la traîne, abandonné comme plate-forme de développement. Faire de Mozilla un navigateur utilisé et reconnu est nécessaire, mais pas suffisant."

"Construire des applications multi-plate-forme entièrement nouvelles, utilisant Gecko, le rendu natif par les thèmes et une bonne intégration bureau/OS. (...) Parallèlement, dès maintenant et en collaboration étroite avec d'autres hackers de l'open source, construire une nouvelle plate-forme applicative unifiée bureau/web à partir de morceaux du code de Mozilla et de GNOME. Partager le code et les efforts, éviter les grandes réécritures. Utiliser les standards autant que possible, ce qui inclue certaines parties de XUL qui sont en cours de spécification. Cette nouvelle plate-forme pourrait même mériter le titre de Mozilla 2.0."

Aller plus loin

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 5.

    Question stupide:
    Derriere les jolies interfaces graphiques faites avec XUL, les traitements sont effectués comment ?
    Avec quel(s) langage(s) ?
    Sur le poste client ou le poste serveur ?

    Et du cote de Microsoft, quel est l'interet de XAML par rapport à une applet ActiveX toute bete ?

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

      pour coder le comportement de l'interface : javascript 1.5
      pour réaliser des traitements plus lourd : composant XPCOM en C++, que l'on peut appeler à partir du javascript (mapping des interfaces des composants vers javascript)

      À terme, pour Mozilla 2.0 :
      comportement de l'interface : javascript 2.0, python ....
      composant XPCOM : C++, peut etre python et d'autres langages.

      http://xulfr.org/wiki/Presentation/Xul(...)

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

      Posté par  . Évalué à 2.

      le plus généralement c'est avec du javascript (enfin c'est ce que j'ai vu pour le moment, c'est sans doute le plus simple) mais d'autre langages sont possible tant qu'il est capable interpreter le DOM en fait

      ca s'execute coté client comme Mozilla (Mozilla et ses camarades sont en XUL)


      ref:
      http://www.xulfr.org(...)
      http://www.xulplanet.org(...)

      Dam

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

      > Question stupide:

      Je ne crois pas qu'il y en ait de stupides...

      > Derriere les jolies interfaces graphiques faites avec XUL, les traitements sont effectués comment ?

      Soit en client-serveur (voire n-tiers), soit en local ?

      > Avec quel(s) langage(s) ?

      Celui que tu veux ?

      > Sur le poste client ou le poste serveur ?

      C'est fonction de ton application ? (besoin ou non de données/traitement centralisés ?)

      > Et du cote de Microsoft, quel est l'interet de XAML par rapport à une applet ActiveX toute bete ?

      Euh... pas la même chose ? XUL/XAML peuvent aller jusqu'à de grosses application gourmandes (c'est "scalable"), et peuvent n'être qu'une couche de présentation ?

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

      J'oubliais
      Sur le poste client ou le poste serveur ?

      Coté javascript, toujours poste client.

      Si il s'agit d'une appli desktop, tout se passe sur le client (forcément), sans restriction.

      Si il s'agit d'une appli web (=client leger riche) : à partir de ton écran en xul, tu n'a pas accés aux composants XPCOM locaux (pour des raisons de sécurité, sauf si ton appli est signée).

      Bien sûr, dans les deux cas, tu peux communiquer avec un serveur http via des services web (XML-RPC, SOAP), et celui ci peut te générer des écrans XUL dynamiquement (pour des applis web, via php par exemple) ou te générer du RDF (format XML contenant les données utilisés pour remplir les widgets graphiques , comme les combo, les treeview etc..)

      Tu peux aussi faire installer sur le poste client des composants XPCOM qui peuvent communiquer avec des serveurs autres que http. par exemple, il existe un XPCOM pour interroger une base mysql. Donc en javascript on peut instancier un objet mysql pour executer des requètes ;-)

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 2.

    Voila une nouvelle comme j'aime !

    Il faut espèrer que l'équipe de Gnome soit prête à faire un grand pas vers Xul/Gecko plutôt que vers Xaml ...

    Et à mon avis c'est maintenant et pas plus tard qu'il faut s'y mettre

    Autre caractéristique de cette nouvelle plateforme: indépendance envers les langages de programation de haut-niveau, gràce à un bon choix d'exécutables au "code géré" (Java, Mono C#, JS2...)
    A mon avis ca va troller sec à ce propos

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 4.

    En complément de lecture :
    http://www.businessweek.com/magazine/content/04_16/b3879009_mz001.h(...)
    C'est d'autant plus interessant (plus facile ?) de s'attaquer à longhorn, que microsoft met de côté certaines nouveautés pour le moment. (bon, tout ça reste à voire)

    En tout cas, ce genre de prise de positions sont - à mon sens - une bonne chose : il est malheureusement bien plus courrant d'entendre le mot fork que le mot alliance, de nos jours...

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

    Il dit

    >Partager le code et les efforts, éviter les grandes réécritures.

    Dans ce cas pourquoi ne pas se resembler avec les autres équipes, par exemple avec KDE. freedesktop.org, X.org

    Je pense que ca serait encore mieux, car il est vrai qu'aujourd'hui l'une des critiques que l'on peut faire sur le libre, c'est que des fois on à l'impression que dans l'open source on réinvente la roue.

    Prenom l'exemple de Gnome et KDE, une majorité de fonctionnalitées sont commune au 2 desktop manager, dans ce cas il serait intéréssant d'en faire un sorte de bibiotheque afin que d'autre interface puisse les utiliser sans devoir tout réecrire.

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

      Posté par  . Évalué à 0.

      Je me permet de rajouter mon grain de sel. Je travaille avec Eclipse depuis qqs semaines et c un vrai bijou ! Swt qui remplace swing est très bien ! Cela m'a réconcilié avec Java !

      Je pense qu'il faut créer une telle plateforme et la baser sur java/Swt avec Eclipse comme Ide principal, XUL pour décrire l'IHM et qqs langages de scripts au dessus pour le RAD pur (avec python par exemple qui sait appeller java) et il faut évidemment garder C/C++ pour développer les bibliothèques techniques et les moteurs d'execution.

      Globallement, je pense que la communauté open source n'a tjrs pas compris que C/C++, c vraiment destiné à une catégorie assez restreinte de programmeur qui font du bas niveau, que python et les autres langages interprétés sont super pour le RAD et pour les non informaticiens mais que seul Java a les caractéristiques (commerciales et techniques) pour être le noyau d'une telle plateforme. Il faut ouvrir les yeux, Java a gagné : J2SE avec Eclipse/SWT, c top, J2ME est la référence des dévs embarqués sur téléphones avec MIDP2, J2EE est LA référence !

      les 2 centimes d'un chti gars qui ne croira a linux que quand ce sera moins le bordel et qui pense que la communauté libre doit absolument en passer par Java pour cela

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

        la communauté libre doit absolument en passer par Java pour cela


        Malheureusement Java ne veut pas passer par la communautée du Libre. Sun a choisi son camp.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 0.

          Ce qui me surprend tjrs dans ce discours sur la liberté de Java c que d'un côté, on prône la diversité, l'ouverture, l'hétérogénéité et de l'autre, on s'arceboute sur les licences libres ou open source.

          Cette histoire de camp ne tiens pas la route. Il y aura des logiciels libres et propriétaires à l'avenir. Comme il y aura du GPL et du non GPL. Ce qu'il faut c faire que le libre prenne plus de place : pour cela il faut passer par Java même en laissant un peu d'argent à Sun car ils l'ont bien mérité après tout.

          Je ne connais pas exactement les limites de la licence Java mais elle ne doit pas être si méchante puisque bcp de grosses sociétés et de petites l'utilise. Je serais intéressé par une référence expliquant ce que l'on risque en développant un projet open source en Java (de payer un jour peut être ?)

          Ne rigolez pas mais par rapport à Java, c vraiment l'usage d'Eclipse/Swt et mes divers expériences J2ME/MIDP2 et J2EE/ObjectWeb qui m'ont fait prendre conscience très récemment que ca y est, Java est devenu la référence que Sun voulait depuis si longtemps ...

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

            T'es en train de nous dire que la seule solution c'est de faire du libre à base de non-libre. Bon ben si le libre n'est pas viable en lui même, c'est pas la peine, on arrête tout de suite et on fait du freeware.

            L'argument est boîteux, de prétendre que la liberté c'est de savoir incorporer les trucs non-libres. Un truc non-libre, c'est pas libre, même si c'est gratuit et vachement bien (au passage, on pourrait débattre de la qualité de Java par rapport à certaines solutions libre, hein :-).

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 3.

            >Cette histoire de camp ne tiens pas la route. Il y aura des logiciels libres et propriétaires à l'avenir.

            Surement, mais pour bien comprendre les raisons de ce débat, il faut bien analyser quelle est la place respective du libre et du proprio.
            L'avantage du libre, c'est indépendance et perennité. Dans cette perspective, les bases doivent etre libres (compilateur, bibliotheques, desktop, ....)
            Le logiciel propriétaire a bien sur sa place, disons pour tout ce qui est marché "de niche" (le terme est peut etre mal choisi) a forte valeur ajoutée.
            J'ai vu comme exemple a cela les bases de données: PostgreSQL ou MySQL (et les autres sgbd libres) satisfont les besoins les plus courants. Si on est dans les 10% qui ont des besoins plus poussés, et bien on se tourne vers le proprio (DB2 ou Oracle (beurk))
            Dans le cas de Java c'est pareil, c'est une brique de base, ca doit etre libre (au moins peut etre la partie J2SE)
            A contrario, un soft de CAO de circuit intégré, ca me choque pas que ce ne soit pas libre, ce n'est pas une brique de base, essentielle, et vu le prix des licences, j'espere que les éditeurs de ces logiciels sont a l'écoute de leurs clients.

            >Je serais intéressé par une référence expliquant ce que l'on risque en développant un projet open source en Java.
            bah tu est totalement dépendant d'une boite, maintenant passée du coté obscur, et que si Sun décide que pour utiliser java, il faudra sacrifier une chevre en dansant la macarena a chaque fois que tu lance ta VM, bah tu sera bien emmerdé.

            >c vraiment l'usage d'Eclipse/Swt......qui m'ont fait prendre conscience très récemment que ca y est, Java est devenu la référence que Sun voulait depuis si longtemps
            Ah ? Sun voulait eclipse/swt comme référence ? :p

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 3.

              Eh non mais Java ce n'est pas que Sun, c aussi IBM et bien d'autres. Sun devra lacher sur Java mais doit etre payé pour son boulot (sauf pour swing, la il faut qu'ils payent tellement c laid et lourd ;) Je ne sais pas si le deal actuel est correct mais effectivement, il faudrait qu'ils le rendent suffisamment libre pour devenir le noyau dont je parlais plus haut.

              Ce que tu dis est vrai et c'est excellent, il fallait que IBM s'y mette pour que java dispose enfin d'un IDE et d'une API pour faire des IHMs dignes de ce nom. On dirais une vrai communauté avec des luttes et tout et tout, ca fait penser à la communauté libre tout ca non ;)

          • [^] # Java sous linux, est ce vraiment possible ?

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

            Quand je vois comment java fonctionne sous linux, j'ai des doutes.

            Impossible de remplir la déclaration d'impots sous linux, j'ai essaye avec 6 navigateurs
            mozilla de 1.2 a 1.6 et netscape de 6 a 7.02 ) et 3 versions de jre (1.31, et deux 1.4.2 sun et blackdown ).

            (
            De nombreux journaus en parlent sur linuxfr
            http://www.google.fr/search?q=site%3Alinuxfr.org+declaration+impots(...)
            liste

            )

            De meme le site transactionnel ( en java toujours ) de boursorama invest ne fonctionne pas sous linux.
            (
            http://neoskills.com/article.php3?id_article=17(...)
            probleme boursorama
            et
            http://neoskills.com/article.php3?id_article=18(...)
            la liste des messages d'erreur
            ( un avis de specialistes java serait le bienvenu, beaucoup de problèmes semblent etre des bugs de leurs applets, mais il y a probablement aussi d'autres problèmes )
            )

            La aussi, j'ai essaye avec 6 navigateurs ( mozilla de 1.2 a 1.6 et netscape de 6 a 7.02 ) et 3 versions de jre (1.31, et deux 1.4.2 sun et blackdown ).

            Il semblerait :

            1- que de nombreux sites sous java ne puissent pas fonctionner sous linux.

            2- que java soit dépendant du compilateur utilisé ( qui devrait etre exactement le même pour le java et le mozilla par exemple )
            je cite http://plugindoc.mozdev.org/faqs/java.html(...)
            " If you are using an old or unofficial build of Mozilla (1.4a or later) or Mozilla Firefox, you can check which compiler was used by entering about:buildconfig in the location bar and pressing enter. You will see a line such as "gcc version 3.3.2", which will show the compiler that was used. If gcc2.9x was used, you need to use the ns610 plugin, not the ns610-gcc32 plugin."

            3- que java ne puisse pas tourner sur un kernel secure ( grsec/pax ) car necessitant une pile executable.

            Dans ces conditions pas facile de dire aux gens de passer sous linux ;(
            ( Si des spécialistes peuvent confirmer/infirmer les points ci dessus SVP )

            Quand a java, qui soi disant devait apporter la portabilité et l'interopérabilité, plus le temps passe et plus je suis persuadé qu'il est moins portable qu'un code C propre et standard assisté d'automake et autoconf.
            Bien trop dépendant de versions précises ou de compilateurs précis.


            F$*K java.

            "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill

            • [^] # Re: Java sous linux, est ce vraiment possible ?

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

              Perso, Je n'ai eu aucun problème pour déclarer mes impôts en ligne. Ma config :

              - Mandrake (je ne me rappel plus si j'étais en 9.1 ou 9.2)
              - Mozilla (de la distrib, donc pas la dernière version)
              - jsdk1.4.2 de Sun (l'archive auto-extractible, pas le rpm)

              Le plus long fût d'installer le jre et le plugin java pour moz, je ne l'avais jamais fait, j'ai dû RTFM.

              • [^] # Re: Java sous linux, est ce vraiment possible ?

                Posté par  . Évalué à 1.

                Moi, pareil. Avec Mozilla 1.4 et Java 1.4.2.

                Evidemment, l'installation du système de crypto des impôts implique de se connecter
                comme root, ce qui complique un peu par rapport à un poste Windows typique.

                D'ailleurs, dans mon expérience personnelle, c'est très souvent des restrictions
                de sécurité qui entraînent des difficultés d'utilisation de Linux.

            • [^] # Re: Java sous linux, est ce vraiment possible ?

              Posté par  . Évalué à 2.

              J'ai un projet en java. Compilé et exécuter avec la JDK 1.3.* de Java aucun problème. Excepté sous linux ou la JRE d'IBM semble mieux marcher.

              J'ai essayé de compiler avec le JDK 1.4*, exécuter avec le JDK 1.3 : bug par ci par la. Pourquoi je n'en sais rien.

              Compiler, exécuter avec le JDK 1.4.* : d'autres problèmes.

              NB: les bugs sont plus coté UI que système mais pas tjrs.

              Au début du projet, je trouvais que java était vraiement bien, surtout avec le bytecode. Maintenant j'ai un peu plus de doute. Et quand tu parles d'avoir un bon code source/un bon autoconf/automake rends le code aussi portable : je suis assez d'accord quand je vois que tous les outils porté pour cygwin et/ou fink, aussi netbsd.

              J'aime bien l'approche description au lieu de code (à la Xul, glabe, XForms même si c'est un peu mastoc) : ca évite les problèmes de ce genre, après chacun son implémentation.

            • [^] # Re: Java sous linux, est ce vraiment possible ?

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

              Pour le point numéro 2, ce n'est pas un problème lié à Java. Le problème c'est la façon dont Mozilla gère les plugins et le fait qu'il n'y a pas de compatibilité entre les binaires fait par gcc 2 et gcc 3.

              Enfin bon... Si il y avait un environnement Java libre suffisament avancé, ça ne serait pas un problème. Les distributions intégreraient les versions de Mozilla et de la JVM qui vont bien et basta. Snif.


              Pour le point numéro 1, une fois un plug-in java complet bien installé, il ne devrait pas y avoir de problème. Une fois de plus, comme ya pas d'env Java libre, c'est surtout un problème pour les gens qui utilisent GNU/Linux sur autre chose que du x86.

            • [^] # Re: Java sous linux, est ce vraiment possible ?

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

              Le logiciel a été développé avec la JVM Microsoft qui contient des extensions non 100% compatibles avec les spécs de Sun (cf. le procès intenté à Microsoft par Sun à ce sujet). Ceci dit, la JVM Microsoft n'avait qu'un but : décridibiliser Java en tant que langage 100% portable. Et effevtivement, quand un problème de portabilité est rencontré avec Java, on accuse Java et on oublie de regarder si l'appli a été développée avec une vraie JVM.

              "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

            • [^] # Re: Java sous linux, est ce vraiment possible ?

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

              Aucun pb pour les impôts sous mozilla, il faut juste se connecter une première fois en tant que root pour installer le plugin java, et après c'est bon.

              Par contre konqueror pas reconnu. Quelqu'un a-t-il essayé avec Safari ?

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

        Je suis plutôt d'accord avec toi sur le fait que Java est vraiment très puissant, et qu'Eclipse est le meilleur IDE que je connaisse (a part evidemment le fameux Wordpad de Microsoft, mais la, on n'y peut rien), mais je pense cependant ton point de vue ne pourrait s'appliquer que par la libération de Java par sun, et je craint qu'il soit maintenant trop tard...

        Sinon, auriez vous trouvé sur le net des applis utilisant XUL, et ne me répondez pas Mozilla, je veux dire par la des applis qui se lance depuis le navigateur (mozilla, firefox), en cliquant sur un lien, comme ce que je pense avoir compris... non????

        Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 1.

        que la communauté libre doit absolument en passer par Java pour cela

        Petite colère...


        • tout le monde a pas les moyens de se payer 2 Go de Ram.

        • Tous les mecs que j'ai rencontré faisant du Java sont des non-techniciens (threads, mutex, IPC, sockets, POSIX ? "connais pas")

        • La plupart des gens qui utilisent Java ont oublié la notion de processeurs ou de mémoires (Procéquoi ? Memqui ?)



        Je ne vois pas en quoi Linux ou UNIX c'est le bordel (à part pour des mecs qui ont commencé l'informatique il y a deux jours)

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 0.

          yep, pour être confort, il faut 512 Mo pour faire du Java. Cela ne vaut plus très cher maintenant et c'est en standard chez Dell par exemple ...

          les threads et les sockets en Java, tu en utilise tout le temps. Par contre, tu n'est pas obligé de te taper des trucs spécifiques à ton OS. Donc arrêtes de rigoler, Java est un vrai langage de prog. De plus en plus d'ingé sont formé avec Java et utilisent Java tous les jours.

          Et oui, Java, c pas du C/C++, et c ca qu'est cool, maintenant, l'informatique a évolué et on peut se permettre de ne pas perdre son temps à penser à la mémoire qui reste : il y a même des gens pour dire que des langages interprétés sont bien car ils sont encore plus haut niveau que Java :) Par contre, on aura tjrs besoin de chtis gars balèzes en C pour coder des bibliothèques en natif super rapides, la dessus, je suis d'accord (cf mes contribs ci dessus)

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

            «pour être confort, il faut 512 Mo pour faire du Java»

            C'est pas spécialement vrai, mon portable ne possède que 256 Mo de RAM, et je pourrais utiliser des logiciels faits en Java.

            Ceci dit je trouve ça assez inquiétant que pour toi le libre doive remonter la barre des exigeances techniques à 512 Mo. Il y a des tonnes d'applications où ce n'est pas envisageable, et tout le monde ne peut pas se procurer une machine dernier cri. À moins d'exclure les pays du Sud, on va se trainer des PII pendant au moins dix ans encore.

            «il y a même des gens pour dire que des langages interprétés sont bien car ils sont encore plus haut niveau que Java»

            Oui, clairement. Si tu as eu une telle révélation avec Java, essaye le Ruby ou le Python, tu verras que c'est beaucoup plus agréable que du Java, et que la plupart du temps la rapidité est au rendez-vous.

            En plus c'est libre, ouahou.

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 0.

              oui, on peut faire du java avec 256 MO mais avec un IDE et un petit apache ou un émulateur, c vraiment plus confortable avec 256 Mo

              Tu as raison, Java n'est pas un kdo pour les pays pauvres. Mais n'oublie pas hier, la chine était un pays pauvre maintenant ils importent plus de matière que nous et demain ils nous boufferont tout cru, miam miam !

              pour les langages interprétés, je connais python, c'était une blague mais j'avais oublié le ;)

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 3.

              Les études prévoient qu'en 2006, la machine de bas de gamme sera sur la base des chiffres 2 et 4

              2 à 4 Ghz
              2 à 4 GO de RAM
              200 à 400 GO de disque
              2 à 4 MO d'ADSL

              Sur le marché de l'occasion, remplacer son PII par un PIII/PIV ne coutera pas cher....

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 4.

                Wharf ! (Désolé)
                C'est quoi cette étude. Elle est faites dans quel quartier de pays riches ? Le principal défaut des vendeurs de machine et des informaticiens veilleurs technologique ; c'est qu'ils oublient qu'en dehors de l'Europe, les USA et du Japon, il existe des pays qui n'ont pas les mêmes budgets à consacrer au renouvellement des parcs informatiques vieillissants. De nombreuses personnes se tapent encore de vieux bousins, même chez nous, et ils se les taperont jusqu'à la fin car budget informatique = not found, please insert money. Les nouveau chiffres sur la progression de la misère dans les pays riches ne sont pas pour améliorer la situation.

                Le marché de l'informatique va stagner car peu de personnes ont besoin d'acheter un ordinateur tout les ans. Les effets de saturation du marché sont peut être déja perceptibles depuis quelques temps. Les investissements et la recherche risque aussi de baisser. Le lancement de longhorn relancera la vente de machines de guerre mais pour combien de temps (heu, je suis un peu vache là dessus :P).

                Le marché de l'occasion, dans nos pays : c'est la benne et des gens qui fondent les circuits pour récupérer le cuivre et autres métaux précieux (qui deviennent de plus en plus rare). C'est presque le même que celui des téléphones portables, d'ailleurs on demande aux constructeurs d'ordinateur d'utiliser des matériaux écologiques.

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 1.

                2 à 4 MO d'ADSL

                C'est tout ? Quelles etudes prevoient ca, alors qu'ici j'ai deja l'ADSL a 45M ? J'espere que vous serez pas si lents a rattrapper le retard, quand meme.

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 1.

                2 à 4 MO d'ADSL

                Moctets/s ou Mbits/s ?

                Même à la montagne ?

                Par ailleurs, pourquoi est-ce que java ça marche sur les téléphones portables... Ils n'ont pas 515mo de ram eux quand même.

                Je rêve et je crois en un monde futur basé sur les principe de l'intelligence collective et du partage du savoir... mais je pense que l'on doit avoir des distributions Linux grand public gratuites et téléchargeables avec pleins (un maximum) de logiciels propriétaires : pilotes, codec, lecteurs, java sun, adobe acrobat... à condition de bien l'expliquer, avec pédagogie et tout...

                M'enfin quoi, si java n'est pas installé par défaut sur les distributions grand publics, on va où ? C'est quand même librement redistribuable, faut en profiter. Après que l'on ne l'utilise pas parceque c'est pas libre, je comprends. Et dire à Sun que c'est le moment où jamais de libérer java, sinon c'est fichu pour eux, ça me parait logique d'après ce que j'ai pu lire ici et là. Mais bon...

                • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                  Posté par  . Évalué à 1.

                  > Même à la montagne ?

                  Chez Free, les 2 Mbits/s sont disponibles sur les lignes de moins de 4000 mètres, et cela monte à 4 Mbits/s si la qualité de la ligne est suffisante.

                  Wanadoo/FT ne fait pas encore d'offre de ce type plus pour des raisons politiques et règlementaires que pour des raisons techniques : dès qu'ils se décideront à le faire, le 4 Mbit/s sera disponible sur tous les NRA adslisés.

                  En plus FT s'est engagé à déployer l'ADSL sur tout NRA où 100 demandes d'abonnement seraient faites (tous opérateurs confondus).

                  Donc, pour répondre à la question, à la montagne, à proximité des gros villages : oui, le 2 Mbit/s sera disponible et sans doute dès l'an prochain.

                  Reste le problème des lignes longues (> 4000 m) et des très petits NRA (quelques dizaines ou centaines d'abonnés), mais peut-être que d'ici là l'ADSL sera intégré au Service Universel et donc la fin du déploiement sera fait aux frais (partagés) de tous les opérateurs.

                  • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                    Posté par  . Évalué à 1.

                    Le Service U-quoi ???

                    Ok, je veux bien, mais dans ce cas, il faudra attendre au moins 2007 ;-)

                    (et ça, c'est seulement si tout le monde à compris d'ici là que ce n'est pas possible avec l'équipe qui nous gouverne aujourd'hui !!!)

                    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                      Posté par  . Évalué à 1.

                      Le "Service Universel", c'est l'ensemble des services que France Telecom est obligé de fournir à un prix unique sur l'ensemble du territoire.

                      Si vous avez une maison pommée sur une ile déserte en Bretagne, ou perchée sur un sommet des Alpes et que vous faites une demande d'ouverture de ligne téléphonique, FT sera obligé de vous cabler pour 46 EUR + 13 EUR/mois quel que soit le nombre de km de cable à tirer.

                      Idem pour certain types de liaisons louées (mais les tarifs ne sont pas du même ordre de grandeur).

                      Pour l'instant l'accès à l'internet "haut débit" ne figure pas dans le cahier des charges du Service Universel, mais il y arrivera sans doute tôt ou tard.

                  • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

                    > En plus FT s'est engagé à déployer l'ADSL sur tout NRA où 100 demandes d'abonnement seraient faites (tous opérateurs confondus).

                    Marrant, chez nous, ils ont exigé qu'on s'engage à s'abonner à wanadoo.

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 3.

              Qu'est-ce que tu appelles des "logiciels fait en java"?
              Mon expérience d'utilisateur avec :

              1/ les installateurs Oracle
              2/ les installateurs IBM
              3/ L'interface graphique Java de Novell 6
              4/ Les développements actuels de ma boite pour faire une interface Java à notre soft (pourtant peu complexe)

              tendent à me faire croire une chose : Java c'est très bien pour plein de trucs SAUF une interface graphique. Une bête interface avec juste une dizaine d'écrans monte rapidement à des occupations mémoire de l'ordre de 90-100Mo. Faire tout un environnement façon KDE en java me parait totalement irréaliste : ce n'est pas 2Go de RAM qu'il faudrait mais 10 fois ça. Et avec une réactivité tout juste passable.
              Il n'y a rien d'étonnant à ce que le 'Java Desktop' de Sun soit essentiellement un Gnome avec un VM Java chargé en permanence. Je doute qu'on ait atteint un point où l'on peut encore se passer des langages compilés pour faire un environnement graphique.
              A moins d'utiliser un système de type PyQT qui est vraiment surprenant de simplicité et de vélocité. Mais une bonne partie reste compilée donc ca ne compte pas.

              Richard.

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 1.

            Et oui, Java, c pas du C/C++, et c ca qu'est cool, maintenant, l'informatique a évolué et on peut se permettre de ne pas perdre son temps à penser à la mémoire qui reste : il y a même des gens pour dire que des langages interprétés sont bien car ils sont encore plus haut niveau que Java

            Quel rapport entre l'interprété et le haut-niveau?

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à -1.

              La plupart (tous?) des languages de haut niveau sont interprétés

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 1.

                Arf, j'aimerais bien lire quelque chose de plus argumenté.

                • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

                  Un exemple parmi d'autres: c'est plus facile d'avoir un langage faiblement type quand il est interprété. Ou d'avoir un langage réflexif et dans lequel tu peux changer des bouts de code à l'exécutions.

                  En C/C++, pour ce dernier point, je suppose qu'il faut recompiler à la volée, et c'est pas terrible.

                  • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                    Posté par  . Évalué à 1.

                    Objective C, c'est compilé, pas du tout typé, et tu peux changer/charger du code a la volée.

                    Au passage, C++ c'est pareil, suffit d'utiliser les bonnes lib (et pas de recompilation)

                  • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                    Posté par  . Évalué à 4.

                    D'accord.
                    Donc, pour vous (/toi), un langage de haut niveau, ce serait un langage faiblement typé ou réflexif, par exemple?

                    Dans ce cas, on n'a pas du tout la même conception du haut niveau. Pour moi, un langage de haut niveau, c'est un langage qui a (au moins) les aspects suivants:
                    - syntaxe et sémantique opérationnelle claires et simples
                    - système de types fort et expressif
                    - abstraction importante par rapport à la machine.

                    La réflexivité entre-t-elle dans ce cadre? La question me semble mal posée (cf. (*) plus bas).

                    Ceci dit, la réflexivité ne fait pas forcément mauvais ménage avec un typage fort, contrairement à ce qu'on peut lire ici ou là. C'est vrai qu'on a intuitivement du mal à croire qu'on puisse les marier mais en fait, si (cf MetaOCaml, ou les langages à n niveaux).

                    Par ailleurs, l'implémentation du typage et de l'exécution sont fortement découplées en général, ou alors il y a un problème dans le langage.

                    J'admets par contre que c'est plus facile d'implémenter la réflexivité dans un interprète, vu qu'on programme ce dernier dans un langage gérant la mémoire à plus haut niveau que le microprocesseur.


                    (*) La réflexivité est un thème qui réapparaît souvent quand on parle des langages de programmation, et on dit souvent que c'est une fonctionnalité nécessaire. Ce qui m'étonne dans ce discours, c'est que la réflexivité n'est qu'une technique, qu'un moyen. Mais il est vrai que c'est assez fascinant, ce qui à mon avis occulte la réflexion (!) qu'il faut entreprendre.

                    La discussion ne devrait pas porter sur la réflexivité elle-même mais sur l'objectif auquel elle est censée répondre. Ce but, laissé souvent implicite, c'est en général la reconfiguration dynamique d'un programme, qui implique la génération et le chargement dynamiques de code. Or pour ça on n'a pas nécessairement besoin en pratique de toute la réflexivité.

                    Utiliser la réflexivité ex abrupto façon Lisp ou même Java, ça revient à contourner le typage (en passant par des quotes ou des chaînes de caractères).

                    Par contre, si on se concentre sur l'idée de reconfiguration dynamique, on peut trouver des primitives cloisonnées (contrairement à la réflexivité) qui suffisent à produire 99% des programmes (facilement 99% du temps) et qui bénéficient, elles, d'une sémantique abstraite (typage) claire et expressive.

                    Dans ces conditions, on a le beurre (la reconfiguration dynamique) et l'argent du beurre (la sûreté assurée par le typage fort).

                    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

                      «Donc, pour vous (/toi), un langage de haut niveau, ce serait un langage faiblement typé ou réflexif, par exemple?»

                      C'est juste des exemples de ce qu'on trouve parmi les langages dits de "haut niveau", que je trouvais assez représentatifs concernant la différence interpretation/compilation.

                      Pour l'indépendance par rapport au matériel, par exemple, l'interprétation est aussi une bonne solution. D'ailleurs si Java est indépendant de la machine c'est en partie parce qu'il est interprété (au niveau du bytecode), ce qui simplifie bien la vie.

                      (Je précise avant qu'on me tombe dessus que l'indépendance par rapport au matériel peut aussi se faire via une bibliothèque bien foutue, mais dans ce cas là ça n'est plus un caractère inhérent au langage.)

                      «[...] on dit souvent que c'est une fonctionnalité nécessaire. Ce qui m'étonne dans ce discours, c'est que la réflexivité n'est qu'une technique, qu'un moyen. [...] »

                      Oula, tu t'embarques bien loin à répondre à des objections que personne n'a formulé ici :-)

                      Pour moi la réflexivité et le changement du code à l'exécution c'est un truc pratique, et ça fait partie de ce que j'aime avoir à disposition, c'est tout. Or c'est infiniment plus facile à faire en interprété qu'en compilé.

                      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                        Posté par  . Évalué à 1.

                        Non non, j'objecte pas :-)
                        Je travaille grosso modo dans le domaine des langages de programmation et c'est donc un sujet qui m'intéresse. J'expose mon avis et mes doutes sur la question de la réflexivité, au sens large, comme paradigme (parmi d'autres) de programmation.

                        Tout à fait d'accord sur le fait que la réflexivité est plus facile à implémenter sur un interprète mais ça n'empêche que ça n'a pas de rapport avec le haut niveau supposé du langage.

                        Pareil pour l'indépendance par rapport au matériel. Rien n'interdit de développer une librairie abstrayant l'OS et de conserver le langage compilé. Évidemment, ça demande du travail mais c'est pas extrêmement compliqué.

                        Mais dans les deux cas, tout ça c'est le problème des concepteurs de l'environnement d'exécution et on peut se poser la question de leur qualité s'ils développent un interprète uniquement parce que c'est dur de faire un compilo et que c'est plus direct pour l'indépendance par rapport au mtériel. Je crains que ça ne soit souvent le cas de pas mal de langages interprétés de la communauté du libre.

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 1.

                Cela m'a l'air asse hasardeux comme affirmation.

                Exemple : Ocaml peut-être au choix compilé en bytecode (~interprété) ou en native code. Et il ne me semble pas dire de bêtise en affirmant que le native code est bien le code natif de ton CPU, soit du vrai code compilé, non ?

                En suite je ne vois absolument pas de limitation théorique qui empêcherait la vraie compilation d'un langage haut niveau. (Et au fait, la technologie JIT de Java, c'est pas du compilé ???)

                • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                  Posté par  . Évalué à 1.

                  Oui j'ai été un peu vite, certains langages de haut niveau (je pense entre e-autres a Objective C, les autres je ne sais pas trop peuvent etre compilés en natif, le truc dans ce cas est que tous les appels entre objets ou procedures sont "deroutes" (a l'edition des liens) sur une librairie d'execution qui se charge des aspects dynamiques du langage. Cependant je me demandes jusqu'ou ce procede peut aller.

                  Pour le moi le bytecode (de quel qu'origine qu'il soit) n'est qu'une pre-interpretation du langage, mais au final il est bel et bin interprete

                  Quand au JIT c'est de la compilation temps reelle (cad que le code est compile au moment de l'execution)

                  • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

                    Pour préciser un peu plus :
                    le bytecode Java a été conçu pour être interprété, et les VM récentes utilisent des techniques d'optimisation pour arranger tout ca : elles "profilent" le code pour déterminer les portions de code les plus utilisées et les compile "à la volée". Celà dis ce n'est pas toujours parfait, et il faut commencer en mode interprété.

                    Si on prend exemple sur le CIL (l'équivalent du bytecode chez .NET et Mono) , celui-ci est optimisé et a été conçu pour être compilé. Il est donc parfaitement possible de compiler le code intermédiaire en code natif, à la volée (JIT), ou même avant exécution.

                    Pour ce uqi est du JIT (compilation à la volée à l'éxecution), il faut juste se dire que c'est la dernière étape de la compilation qui a lieu, elle est juste retardée au dernier moment, notamment pour que le code soit plus "portable". (il faut bien se dire qu'il y a également un code intermédiaire dans GCC)

                    Dans tous les cas, qu'il s'agissent du bytecode Java ou du CIL, on peut compiler ou intepréter, seulement l'un est optimisé pour la compilation et l'autre pour l'interprétation...

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 0.

            il y a même des gens pour dire que des langages interprétés sont bien car ils sont encore plus haut niveau que Java

            Ce que tu oublies de dire, c'est que les langages interprétés en question utilisent en général beaucoup moins de mémoire que Java... Au fait, tu as le droit d'utiliser des mots entiers au lieu de t'exprimer comme un publicitaire shooté à la coke.

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 2.

          ># tout le monde a pas les moyens de se payer 2 Go de Ram.
          Mon serveur d'application "perso" a tourné avec mes applis "perso" (cad une environs 1000 connexion/mois) avec seulement 24Mo pendant 4 ans...

          ># Tous les mecs que j'ai rencontré faisant du Java sont des
          >on-techniciens (threads, mutex, IPC, sockets, POSIX ? "connais pas")
          Tous les mecs que rencontre PBPG sont pas tres doué pour faire des scripts Bash...

          ># La plupart des gens qui utilisent Java ont oublié la notion de
          >rocesseurs ou de mémoires (Procéquoi ? Memqui ?)
          La plupart des gens que tu connais peut-etre. Les autre, pas certains. Ca fait 7 ans que je suis dev Java et tous ceux que je connais savent ce qu'est un Thread, n'ont pas perdu la notion de mémoire ou de processeur, savent faire des connexion par socket, etc.

          Malgre ces points ou je ne suis pas d'accord, je pense effectivement que la communauté du libre n'a pas particulierement besoin de passer par Java pour son avenir... Java, si sun ne l'ouvre pas, disparaitra, tout simplement.

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          Là faut pas déconner.

          > tout le monde a pas les moyens de se payer 2 Go de Ram.

          Ouh la c'est de la provocation ?
          As-tu déjà utilisé récemment depuis le jdk 1.4 des GUI développés en SWING (j'insiste par rapport au FUD SWT c'est génial / SWING de la daube).
          Un très bon exemple "intellij idea" un IDE java très apprécié de la communauté Java , il est très rapide et tourne facilement sur un machine avec 256 Mo. Essaie par toi même.

          > Tous les mecs que j'ai rencontré faisant du Java sont des
          > non-techniciens (threads, mutex, IPC, sockets, POSIX ? "connais
          > pas")

          Encore de la provoc. Déjà s'ils ne savent pas ce qu'est un thread ou une socket, c'est vrai que ça fait peur mais c'est pas le cas des dév Java que j'ai pu cotoyer ( peut-être pour les dev VB).
          Les dev Java touchent à d'autres problématiques de plus haut niveau, comme l'intégration à des systèmes tiers là ou Java excelle: mapping O/R, transactions distribuées XA, échange de messages asynchrone JMS, etc.
          Bref, les problématiques sont souvent moins proches du matériel ou de l'OS mais peuvent être tout aussi complexes... C'est tout l'intérêt de ce language. A chaque tâche son outil, je n'irai pas coder le driver de mon imprimante en Java.

          >La plupart des gens qui utilisent Java ont oublié la notion de processeurs ou de mémoires (Procéquoi ? Memqui ?)
          C'est ça et ils s'inquiètent de voir un mulot à côté du clavier !

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 2.

            ... un IDE java très apprécié ...tourne facilement sur un machine avec 256 Mo...

            C'est de l'auto-dérision ? :-)

            Je crois qu'il est urgent de mettre au courant la bande de débiles mentaux qui utilisent encore le C et le C++ pour faire des projets multi-plates formes du style de (à la volée) Gimp, MySQL, Apache, Gaim, Mozilla, Blender, Pov, PHP, Perl, Celestia...rien que des projets multi-plate forme fonctionnels et opérationnels (tu as remarqué, c'est pas des éditeurs de texte, c'est pas que du Web...)

            Dans une moindre mesure et à une échelle très modeste, je viens de boucler un soft pour ma boite d'océanographie. 11000 lignes de code de C/Gtk. Ca compile sous Linux et sous Windows en natif sans Cygwin. Le delta entre les deux versions: 50 lignes ( 0.4% du code est platform dependant, houalala la galère...). C'est vrai que si j'avais utilisé Java, j'aurais mis au moins trois jours de moins....le gachis...

            Screenshot: http://dpithon.free.fr/gtkwin.jpg(...)

            On passe plus facilement du C au Java que le contraire pour peu qu'on ai des bases théoriques solides en objet (j'ai commencé avec CLOS....). D'ou mon commentaire caricatural sur l'ignorance des codeurs Java...

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

            «As-tu déjà utilisé récemment depuis le jdk 1.4 des GUI développés en SWING (j'insiste par rapport au FUD SWT c'est génial / SWING de la daube).»

            Moi oui, et sincèrement, SWING c'est de la daube. Ça rame sur un portable que j'ai acheté en septembre 2003, c'est inadmissible et ça donne une mauvaise image de Java qui n'est pas si lent que ça en réalité. C'est ce qui fait que sur slashdot hier des gens critiquaient l'utilisation de Java pour faire des calculs scientifiques distribués, alors qu'en fait c'était un choix parfaitement adapté.

            Certes, c'est moins lent qu'avant, mais quand je vois un programme tout simple qui rame sur une machine que je trouve trop puissante pour ce que j'en fais, non merci.

            (Si je dis ça, ce n'est pas pour troller sur Java, j'aurais de bien meilleures pistes de trolls à ce sujet hein :-)

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 1.

              Java pour faire des calculs scientifiques distribués, alors qu'en fait c'était un choix parfaitement adapté.

              Dans l'océano c'est Fortran (PGF) et C (du moins chez moi).

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

                J'ai pas dit que c'était adapté dans tous les cas, juste dans le cas dont je parle :-)
                Il s'agissait d'un type qui voulait que "les gens" l'aident à faire ses gros calculs, en faisant tourner une appli en tâche de fond pendant un mois. Une sorte de Seti@Home en moins distribué.

                Sachant que pour avoir un maximum de contributeurs il faut un truc portable et simple à installer, et sachant qu'il ne doit pas être un informaticien professionnel, Java est une solution adaptée. D'autant plus que sa lenteur ne sera pas pénalisante, car sur un calcul d'un mois, les parties lourdes seront compilées par le JIT.

                Donc pour moi, c'était un choix correct. Je précise d'ailleurs qu'il s'agit de la plateforme Java, pas le langage, car il peut très bien avoir codé le tout en ADA, et compilé pour une JVM, par exemple.

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 1.

                Et je me réponds à moi-même, au CIRAD Forêt à Montpellier (modélisation de grands végétaux) ils sont partis initialement sur une plate-forme C++ et ils s'orientaient vers du python aux dernières nouvelles que j'en ai eu.

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 3.

                Java pour faire des calculs scientifiques distribués, alors qu'en fait c'était un choix parfaitement adapté.

                Dans l'océano c'est Fortran (PGF) et C (du moins chez moi).

                Si, si, le java est parfaitement adapté pour faire tourner des calculs sur deux machines alors qu'une seule suffirait avec du C ou autre :-)

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 1.

              >Moi oui, et sincèrement, SWING c'est de la daube.

              Bon ça c'est ton expérience perso. Ce qui est sûr c'est que SWING c'est pas la partie de la plateforme JAVA qui jouit de la meilleure réputation. ..
              Je pense simplement que c'est un bon choix aujourd'hui pour développer une application de gestion (non temps réel) en entreprise dans un environnement hétérogène.
              En fait, non pas pour SWING lui même, qui produit aujourd'hui des interfaces multi-OS "potables", sans exiger trop de connaissances bas niveau mais surtout pour avoir accès à la richesse des librairies JAVA. Quand ton GUI doit s'intégrer à des systèmes tiers avec RMI , JDBC ( SGBDR), JCA ( connecteurs vers mainframes), JNDI ( LDAP, DNS), etc. La plateforme Java J2SE+J2EE est riche et c'est un gain de temps appréciable que de pouvoir s'affranchir de considérations systèmes que tu dois gérer un C. Et ceci sans pour autant trop te limiter: si tu veux faire appel à des API natives en C/C++ tu peux toujours le faire avec JNI.

              Pour en revenir, au débat, le futur XUL ou XAML/Avalon visent tout à fait ce public là: les développeurs de GUI d'entreprise ( à la VB). Pour générer rapidement des clients lourds plus riches en fonctionnalités que des clients légers et presqu'aussi "simplement". A mon sens que "le futur concurrent de XAML" ne supporte pas le Java c'est se priver d'une plateforme complète pour développer ce type d'applications fusse-t-elle propriétaire ( mais concurrente de DotNet).

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

              Essaie une application _bien programmée_ en Swing !! Ca veut dire quoi Swing c'est de la daube ? Je peux te faire des trucs tout pourris lents et laids en QT, est ce que c'est pour ça que QT c'est de la daube ??

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          Tous les mecs que j'ai rencontré faisant du Java sont des non-techniciens (threads, mutex, IPC, sockets, POSIX ? "connais pas")

          Franchement c'est à mourir de rire. Heureusement que les dev java connaissent ce genre de notions, ne serait-ce que pour utiliser un pattern singleton thread-safe. Et les "synchronized" ça sert à quoi d'après toi ?
          D'autant que les notions dont tu parles existent en Java exepté les IPC (bien qu'il soit possible d'en émuler le comportement en se débrouillant avec des sockets), je te conseille d'aller jeter un coup d'oeil au package java.net., tu seras etonné de voir ce qu'on y trouve.

          La plupart des gens qui utilisent Java ont oublié la notion de processeurs ou de mémoires (Procéquoi ? Memqui ?)

          Mais bien sur ! Est-ce que tu as déjà été sur un projet java sérieux ? L'optimisation en Java est clairement basée sur l'optimisation de l'utilisation mémoire, le cycle du garbage est vital pour avoir des performances correctes idem pour le comportement de la heap (les paramètres -Xms et -Xmx sont par exemple importants).
          L'existance en Java d'un garbage collector fait que la libération des ressources est moins problématique mais cela reste tout de même une préoccupation majeure. Et d'ailleurs, le fait que des logiciels tels que OptimizeIt de Borland ou JProbe existent montre que les notions de processeurs et de mémoire ne sont clairement pas oubliées.

          Tu as raison de mettre "connaissances de base en Java" sur ton cv. Lire ce genre de conneries ça me gacherait presque mes vacances :-)

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 8.

            Franchement c'est à mourir de rire.
            Je suis ravi de te faire rire, pas besoin de steack ce midi.
            Maintenant pour l'argument. Un mec qui vient du C, qui se palluche la mémoire, les pointeurs dès le départ parce qu'il n'a pas d'autre choix est largement plus poilu qu'un gentil developpeur Java qui vit dans son monde de bisounours. Il est sensibilisé au système dès le départ. Point.

            Est-ce que tu as déjà été sur un projet java sérieux ?
            Oui, sur un projet français qui s'appelle SDX (pour le minisitère de la culture, http://adnx.org/sdx/,(...) dans le cadre de mon ancien job). Extension de Cocoon. C'est gros mais ça marche très bien.

            les paramètres -Xms et -Xmx
            Merci, je connais....Et je parle des Javanais, pas tellement du pour ou du contre sur Java (le contre c'est la mémoire et la vitesse sur Linux)

            "connaissances de base en Java"
            Oui ça s'appelle de l'humilité. Ce qui ne veut pas dire conaissance de bases en Objet (CLOS, Eiffel, C++ et Python sont mes amis)

            Si je m'autorise ces critiques dans ce milieu autorisés c'est que je bosse depuis 4 ans, que des langages je commence à en connaître (Du GFA Basic au x86, en passant par le 68000, le C ou le LISP) et que j'ai cotoyé pas mal de dev en tout genre dans mes deux précédentes boites. Verdict. Les mecs en C sont plus balaises et ont une culture informatique largement plus étendues. C'est mon avis et vous m'y ferez pas renoncé. Ca veut pas dire que tous les mecs qui vont du Java sont des cruches. Mais on peut faire du Java sans rien connaitre d'un ordinateur (suffit d'aller chez Alcatel, j'ai un pote qui en rigole encore), en C c'est un peu plus compliqué...

            Vous pouvez moinssez. Lacher vous les gars. Faites vous plaisir.

            Quand je vois des types qui disent:

            "Ha ouais, super, J2EE et tout. On va prendre ce FrameWork de la mort qui tue et on va leur montrer aux minus d'UNIX comment qu'on fait des applis pour les end-user...". Désolé ça m'énerve.

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 2.

              Ben... désolé mais ça ressemble plus à une frustration personnelle qu'à une évidence etayée par des faits.
              Il y a des cons partout, ne t'inquiète pas!

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 6.

              Maintenant pour l'argument. Un mec qui vient du C, qui se palluche la mémoire, les pointeurs dès le départ parce qu'il n'a pas d'autre choix est largement plus poilu qu'un gentil developpeur Java qui vit dans son monde de bisounours. Il est sensibilisé au système dès le départ. Point.

              Qui a dit le contraire ? Un programmeur C est confronté au problème de la mémoire dès la phase de programmation et le dev Java s'en soucie moins pendant cette même phase, c'est une évidence. En revanche, il est clairement obligé de le prendre en compte pendant les phase de tests et d'optimisation (les memory leaks existent aussi en Java). En ça il est sensibilisé au problème et une bonne connaissance de la structure mémoire de la JVM est indispensable.
              Autre chose, par exemple, les conteneurs Java ne sont pas tous thread-safe et les programmeurs Java doivent toujours prendre en compte l'aspect multi-thread dans le choix de ces conteneurs. La mémoire joue ici aussi un rôle important puisque certains conteneurs sont très rapides en lecture et écriture mais induisent la création d'index pour accelerer les accès et peuvent donc poser des problèmes lorsque les collections contiennent une grande quantité d'objets. Les OutOfMemoryException ce n'est pas seulement dans les cauchemards.
              Bref ce que je te reproche c'est de sortir des lieux communs sur Java sans véritablement prendre en compte le fait que pour bien connaitre et utiliser Java il faut nécessairement comprendre les notions de threads, de mémoire et de processeur.

              Les mecs en C sont plus balaises et ont une culture informatique largement plus étendues

              Puisqu'apparemment l'expérience personnelle a ici valeur de preuve, je vais moi aussi y aller de mon expérience. Je travaille sur les parties backend d'un gros projet J2EE, en gros MQseries, Moniteur transactionnel CICS, DB2 etc. Je cotoie donc 2 mondes :

              - Celui des programmeurs COBOL capables de te dire la différence de réprésentation mémoire entre S9(4) COMP et S9(4). Je fais partie de ces gens-là aussi puisque j'ai écris des programmes COBOL.

              - Celui des devs Java pour qui les notions d'encapsulation, d'objet sont importantes. J'en fais aussi partie puisque comme je le disais j'ai écris la partie Java de connexion MQ, d'envoi et de création des messages.

              Et bien, il n'y a pas pour moi de grosses différence de culture entre ces 2 mondes. Pour la simple et bonne raison que aucun des devs Java n'a fait que du Java dans sa vie de programmeur. Et bien que j'ai quitté le monde des écoles d'ingénieurs depuis un petit bout de temps, je ne crois pas que les étudiants n'apprennent que du Java durant leurs études.
              Je crois moi que tu as une culture "bas niveau" et que donc tu "idolatres" les programmeurs C parce qu'il correspondent à ta conception de l'informatique, c'est un droit mais laisse moi douter de ton objectivité lorsque tu parles des dev Java.

              "Ha ouais, super, J2EE et tout. On va prendre ce FrameWork de la mort qui tue et on va leur montrer aux minus d'UNIX comment qu'on fait des applis pour les end-user...". Désolé ça m'énerve.

              Le serveur d'application IBM WebSphere fonctionne très bien sous AIX ... je vois vraiment pas où tu as pu entendre ça. D'autant que ça ne veut presque rien dire J2EE c'est plutôt du client/serveur avec des conteneurs et il n'y a pas de notions purement "Unix" équivalente . Java et Unix ne sont pas antinomique. OK Java a mauvaise presse du coté de Linux pour des raisons de licence mais IBM contribue à améliorer Java pour les plateformes Unix.
              Finalement si les gens prenaient le temps de connaitre vraiment les technos, on aurait probablement une meilleure collaboration à tous les niveaux, entendre "Haha on va leur expliquer la mémoire à ces tapettes de programmeurs Java ..." c'est énervant aussi.

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 4.

                Bon, j'enterre la hache de guerre...J'aime pas me disputer avec des gens surtout quand ils sont intelligents. Désolé, pour les Javaistes (nais) que j'ai blessé. Pour résumer ma hargne qui dure depuis hier soir, et ne pas faire un infarctus à 30 ans :

                J'entends dire (ou plutôt, je lis) ici et là que :

                - Java devrait remplacer [Machin Chouette]
                - On devrait utiliser Java à la place de...
                - [Langage TrucMuche] est vraiment moins bien que Java
                - Si on réécrivait [TrucBidule] tout en Java
                - ...

                (C'est aussi un peu valable pour Python.), par des gens parfois très compétents. Rien que dans les commentaires de cette news qq'un proposait de baser le FW applicatif de Linux sur Java. Je ne suis pas d'accord. UNIX a toujours eu un souci d'interopérabilité en même temps qu'une approche assez homogène des problèmes. Baser tout sur Java, en disant: "On recommence tout", ca me parait improductif pour rester poli.

                entendre "Haha on va leur expliquer la mémoire à ces tapettes de programmeurs Java ..." c'est énervant aussi

                C'est vrai, je caricature à coup de tronçoneuse le developpeur Java. Mais les developpeurs C supportent à longueur de journées des inepties sur les inaptitudes et des problèmes soi-disant inhérents au C, notamment le fait que le C ne serait pas une solution sérieuse pour développer des applis portables (voir un de mes posts un peu plus haut), alors je tombe (bêtement, certes) dans l'excès inverse...

                Allez, j'arrête :-)

                Sans rancunes?

                • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                  Posté par  . Évalué à 2.

                  Baser tout sur Java, en disant: "On recommence tout", ca me parait improductif pour rester poli.

                  Je suis tout à fait d'accord avec toi (si si :-). Mais globalement c'est une sorte d'effet de mode, j'entends dire la même chose à propos du mainframe, du COBOL etc depuis longtemps. On ne répetera jamais assez que pour chaque usage il y'a un langage adapté.

                  Sans rancunes?

                  Bien sûr ! Je suis en vacance, la vie est belle ! :+)

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

          # Tous les mecs que j'ai rencontré faisant du Java sont des non-techniciens (threads, mutex, IPC, sockets, POSIX ? "connais pas")

          C'est quand même beau la généralisation :-)

          Euh ... Je suis développeur Java et durant mon graduat en informatique industrielle j'en ai bouffé des IPC, du POSIX, .....

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 1.

            cest vrai qu'il a un peu généralisé, néanmoins j'ai également l'impression que les entreprises pensent que java est le "langage promis", simple a apprendre, a deployé, portable... du coup on se retrouve avec des dev n'ayant que peu de connaissance en java, voir en objet, dévelloppés des gros projets.

            Néanmoins je prefere tout de meme un langage tel ruby, python, C#, meme si les possibilités ne sont pas les mêmes que java... question de gouts.
            S'uniformiser sur un seul langage n'est a mon avis pas une bonne idée, même s'il est très couteux de developper plein de bindings.

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 1.

        c'est pour le record du plus gros troll?

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 2.

        Eclipse est un très bon logiciel qui plus est est très évolutif. J'y vois presque la nouvelle usine qui devrait remplacer Emacs (euh ... pas tapper !!!).
        Bref, tout ça pour dire que si tu aimes Eclipse, c'est très bien, mais ça ne force aucunement à utiliser Java, pas plus qu'Emacs ne t'oblige à développer en elisp, car il existe de nombreux modes Eclipse pour divers langages. (même pour Eiffel !!!)

        Quant à l'intérêt de Java pour la communauté libre, voir les nombreux trolls qui n'ont pas manqué de hanter les lieux --> il en ressort que développer du libre en Java n'a pas trop d'intérêt en général, même le jour où le monde propriétaire entier l'utilisera.
        En effet, la principale "killer feature" est la portabilité du "bytecode", argument qui devient caduc dès que le source est disponible. Tu pointes quelques autres avantages, mais je pense qu'on peut trouver l'équivalent dans d'autres langages plus "libres". (La communauté open source connaît bien d'autres langages que "C/C++" ou "python et [...] autres langages interprétés" !!!).

        Voilà pourquoi je pense que de notre point de vue, Java ne peut être guère plus qu'un langage parmi d'autres.

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

          désolé de te dire ça, mais toi tu sembles ne pas avoir compris l'interet d'avoir du byte-code...

          En théorie :
          1) c'est justement pour eviter d'avoir à recompiler selon la plateforme, donc d'executer le logiciel sans avoir à chercher des builds spécifiques à sa machine/OS. Toi t'es peut être un warrior, à ne pas avoir peur de faire une compil, mais on n'a pas tous envie d'avoir à compiler un logiciel que l'on a récuperer pour pouvoir l'executer, ni avoir le temps, ni avoir les moyens (installer tout un tas d'outils) etc...
          2) le fait d'avoir un environnement d'execution cloisonné (la JVM)
          3) Et du fait de la JVM, de ne pas à s'occuper de gestion de mémoire, et tout autre opération bas niveau.

          Bref, la "killer feature" comme tu dis, ça n'est absolument pas rendue caduc par le fait d'avoir les sources.

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 0.

            Et toi, tu n'as pas compris l'interet d'avoir les sources :-)

            Avec de vrai OS, tu ne recompiles/cherche pas tes applications, mais tu demandes juste je veux utiliser ca. Et tout seul ta petite distrib Linux va installer la bonne appli (apt-get, urpmi, ...). Tu n'as pas besoin de compiler, c'est deja fais pour toi.

            L'environnement cloisonne... La bonne blague, on a pas les sources des JVM. Il y a de tres grandes chances que les plantages de ces JVM sur du bytecode ecrit a la main permette de faire de joli virus (Il y avait une conf sur le sujet au Chaos Computer Camp). Donc tant qu'on a pas les sources de ces JVM, il n'y a pas de securite assure.

            La gestion memoire en JAVA... Tu en as deja fais sur telephone mobile ? Et bien si tu ne veux pas que ton appli ce crasch en moins d'1s parce qu'elle a bouffe trop de memoire, faut appeler manuellement le garbagge collector ! Et franchement qui mieux que celui qui alloue (developpeur) sait quand desalloue (Jette un coup d'oeil aux algos de garbagge collector, tu verras il y a des tas de cas foireux qui peuvent poser probleme et ou ta memoire ne sera jamais libere...).

            J'ai vraiment du mal a voir en Java autre chose qu'une decision de decideur presse qui ne l'a jamais utilise et ne l'utilisera jamais.

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 1.

              Avec de vrai OS, tu ne recompiles/cherche pas tes applications


              Ah bon ? Alors ça sert à rien les sources !

              L'environnement cloisonne... La bonne blague, on a pas les sources des JVM.


              D'abord on a les sources. Sur le site de sun il faut s'enregistrer, puis accepter pleins de licences, et ... paf, les sources des jvm (de sun)
              Après tu pourrais vouloir les sources d'autres jvm: sablevm, kaffe, kawa (GNU), et j'en oublie. J'ai même lu qu'il y en avait certaines d'écrites (presque entièrement, seulement, bien sûr) en java.

              Il y a de tres grandes chances que les plantages de ces JVM sur du bytecode ecrit a la main permette de faire de joli virus


              Déjà, une JVM, par défaut, vérifie le bytecode, lorsqu'il est chargé. Elle est, si je ne me trompe, capable de vérifier qu'il ne charge pas d'autres .class comme ça, discret, sans prévenir, qu'il ne fait pas de "pointeurs" (au sens bytecode du terme) pour examiner l'ensemble de la mémoire de l'environnement Java, et il doit y avoir d'autres vérifications.

              Ensuite, l'utilisateur peut facilement régler la sécurité. Ex: une applet ne peut pas écrire sur le disque, et une appli locale, elle, le pourra. Et si ça plante... la réponse est peut-être insatisfaisante, mais: c'est un bug ! Si on en fait quelque chose de méchant, c'est un exploit. (Mis à part le fait que cela me paraisse irréaliste) il y a des exploits pour des trucs qui ne sont pas du java, même pas des trucs exécutables. On a vu des exploits HTML pour IE, ou encore:

              http://www.us-cert.gov/cas/techalerts/TA04-099A.html(...)

              Il pourrait aussi y avoir un root exploit dans libjpeg, tant qu'à faire. Mais ce qu'il faut se dire, c'est que l'environnement Java est open source, et à vraiment été conçu de manière à éviter ces écueils, et est une autre réponse aux problème de l'isolation que la méthode utilisateurs/process/protection mémoire (qui a aussi des trous)

              Et bien si tu ne veux pas que ton appli ce crasch en moins d'1s parce qu'elle a bouffe trop de memoire, faut appeler manuellement le garbagge collector !


              Mauvaise réponse. Il faut rajouter de la mémoire à la machine, ou bien en faire consommer moins à l'application. Quand ton appli se fait killer par le système, car il y a plus de mémoire, tu n'as pas de <magie>Garbage Collector</magie> à appeler

              Jette un coup d'oeil aux algos de garbagge collector, tu verras il y a des tas de cas foireux qui peuvent poser probleme et ou ta memoire ne sera jamais libere...


              Moui, ben jette un coup d 'oeil aux bons algos de garbage collector, et tu verras que il y a pas de problèmes. Notamment avec des cycles. C'est sûr qu'avec des cycles énormes... ça peut devenir un petit peu moins efficace, mais ils n'arrivent que rarement dans de vrais programmes; à tout casser, il y a une 20aine d'indirection pour faire le cycle.

              A+

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 1.

                > il pourrait aussi y avoir un root exploit dans libjpeg,

                Heu comment dire... Il pourrait y avoir un trou dans la libjpeg, mais *root* ca ne depend que des programmes qui l'utilisent... Sur mon système a priori je vois pas.... Enfin ca doit etre possible.

                • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                  Posté par  . Évalué à 1.

                  Groumph, mouais d'accord... Bon. D'une part, mes mots ont dépassé mes pensées.

                  D'autre part, en essayant de me justifier un tout petit peu a posteriori, c'est réellement impossible pour un user de passer admin sans exploiter un programme setuid mal blindé ? Y a pas des histoires de mremap et compagnie qui permettent à un utilisateur de passer root ?

                  Donc, si libjpeg utilise mremap, on peut passer root avec !

                  • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                    Posté par  . Évalué à 1.

                    Non c'est n'a rien avoir. Bon il est tard je vais faire ca tres grosso modo. Tu as

                    1/ Faille noyau distante : la c'est imparable ca permet de prendre le controle du noyau donc de la machine. Exemple faille dans tcp_input, netfilter et plein d'autre endroits. Generalement c'est assez rare et en fait c'est plus souvent des leak de mémoire qu'autre chose

                    2/ Faille noyau locale : permet de passer root si tu as un access local a la machine. Exemple : les failles recente du noyau (mremap entre autre). Un access local ca peut aussi bien etre un script php foireux qui te laisse une uid apache qu'un vrai compte...

                    3/ Faille dans un demon qui tourne avec des privilege (root ?). La tu exploses un service qui avait une uid priviligiée et donc tu recupères les privilèges avec lesquels il tournait. ca peut etre apache ou root... Une variante est justement le programme setuid qui va tourner sous des privilège différent des tiens et a qui tu peux passer des variables un peu bizarres !

                    4/ Faille dans un programme qui tourne sur tes droits. Bin la y'a pas grand chose a faire....

                    5/ Faille dans une lib, ca se rapporte a 3 ou 4. Tout dépend dans quel contexte elle est utilisée. Donc un "root exploit" c'est un faille noyau, une faille dans un demon qui tourne sous root ou dans un programme que tu peux appeler et setuid root. Un faille dans openssl sera critique alors qu'une faille dans libmachin sera peu etre moins grave....


                    Vala c'etait dans le basique mais mon lit m'attire :-)

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

                Posté par  . Évalué à 2.

                >D'abord on a les sources. Sur le site de sun il faut s'enregistrer, puis accepter
                >pleins de licences, et ... paf, les sources des jvm (de sun)

                Surtout ne touche pas a ca, tu risquerais de ne plus pouvoir contribuer a des implémentations libres de Java

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          Eclipse est super surtout pour java mais aussi pour plein de langage : je suis Ok a 100%

          Je pense qu'il n'existe pas de langage universel : c évident, le langage n'est qu'un outil. A chaque clou son marteau : je suis Ok a 100%

          Par contre, l'argument, on a le code donc on peut recompiler ou on veut : bof ! Pourquoi mozilla a créé Xul a ton avis ?

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          pas plus qu'Emacs ne t'oblige à développer en elisp

          Ne voulais-tu pas écrire "développer en slip" ?

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 4.

        les 2 centimes d'un chti gars qui ne croira a linux que quand ce sera moins le bordel et qui pense que la communauté libre doit absolument en passer par Java pour cela
        Je pense qu'il serait completement incoherent pour des developpeurs de logiciel libre de batir une plate-forme sur une JVM alors qu'il existe une specification standard (ISO et ECMA) d'une machine virtuelle performante qui a ete concue de maniere a laisser aux developpeurs le choix du langage. http://www.ecma-international.org/publications/standards/Ecma-335.h(...) . Quel que soit le langage utilise, le code source est compile en CIL (Common Intermediate Language). Cela offre d'enormes avantages : Il suffit donc de faire par exemple un binding des bibliotheques de la plate-forme de developpement Gnome dans le langage de son choix (ici en c# http://gtk-sharp.sourceforge.net/(...)), de le compiler en CIL, et tous les langages supportes par un compilateur CIL pourront directement utiliser ce binding. Voici une liste non exhaustive de bindings disponibles :

        OpenGL bindings.
        Mozilla bindings.
        Evolution data store bindings.
        Gtk bindings (gtk, gdk, atk, glade)
        Gnome bindings (gnome, canvas, vte)
        XML-RPC bindings.
        iFolder
        Simias.
        LDAP access (Novell.LDAP)
        CORBA stack (sadly, it does not use ORBit)
        Cairo bindings.
        Lucene.NET search engine.
        Mono.Security: underlying mono implementation for all things crypto (SSL/TLS implementation included).
        ECLA CLI image manipulation library.

        que seul Java a les caractéristiques (commerciales et techniques)
        En ce qui me concerne, je pense que l'argument technique est le plus important lorsque l'on fait du logiciel libre. En l'occurence je pense que C# est plus adapte que Java comme langage de haut niveau pour coder des applications graphiques. Il possede certaines facilites que Java n'a pas (notamment le concept des attributs (http://www.dotnetguru.org/articles/CSharpVsJava.htm#_Attributes(...)) qui est tres pratique). A noter qu'il existe une machine virtuelle Java qui tourne au-dessus de cette CLI decrite dans l'ECMA-335 (http://weblog.ikvm.net/story.aspx/faq(...)).

        PS: Vous aurez remarque que j'ai soigneusement evite toute mention de ".NET" ou de Microsoft. Cela pour bien faire comprendre que nous parlons ici de standards documentes, et non d'une "technologie a Microsoft".

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          Je pense qu'il serait completement incoherent pour des developpeurs de logiciel libre de batir une plate-forme sur une JVM alors qu'il existe une specification standard (ISO et ECMA) d'une machine virtuelle performante qui a ete concue de maniere a laisser aux developpeurs le choix du langage. http://www.ecma-international.org/publications/standards/Ecma-335.h(...)) . Quel que soit le langage utilise, le code source est compile en CIL (Common Intermediate Language).

          Y'a quand même un problème : cette machine virtuelle, comme la JVM, et comme toute MV, a été développée avec certaines fonctionnalités en tête. En l'occurrence, elle a été prévue pour être la cible d'un langage à objets. Par contre, elle n'est pas adaptée à l'exécution des langages fonctionnels.

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

            Vi, enfin faut voir aussi ce qu'on veut : avoir une plateforme plus ou moins "universelle" pour le desktop : et le fait est que la plupart des composants actuels de l'OS sont constitués d'API basé sur des langages qui n'ont rien de fonctionnel mais par contre avec une bonne dose d'objet pour ce uqi est des interfaces... c'est peut être pas pour rien que Microsoft et Mono ont fait ce choix... De plus un langage fonctionnel peut aussi être objet, et peut donc très bien s'intrégrer avec cette plateforme, et c'est d'ailleur le but. L'inverse est beaucoup moins vrai.

            Après les langages fonctionnels font tous le même taf et finisse par créer du code itératif de base, ce qu'une VM propose bien évidemment. Reste que si tu veux optimiser pour certain langages fonctionnels, rien n'interdit de "factoriser" les points communs et d'intégrer ces possibilités dans la VM... notamment la VM de l'Ecma qui n'est pas du tout hostile aux évolution contrairement à celle de Sun (voir le résultat foireux des generics pour continuer à utiliser les VM actuelles...).

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 1.

              Un peu hors sujet, mais cest quoi un générique (perso jai pas trop vu la difference avec un template, mais jai pas vraiment étudié la question a fond) ?

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

                Disons que les templates en gros le compilo il se fait pas trop chier : il compile la classe générique avec le type object. Et pour faire semblant d'avoir réussi son tour de passe passe, il fait pas dans le détail : il rajoute des cast partout. Voilà pour la solution Java. Avantage : ça marche sur les VM actuelles sans problème (et pour cause, c'est juste de la bidouille syntaxique à la compilation)

                Pour ce qui est de l'implémentation du C#, le code est remplacé à l'éxécution par son vrai type. Ca change quoi ? Tout. Tout d'abord le code est partagé par toutes les instances de la classe "générique", et surtout, à l'exécution, une classe générique reste une classe générique et toutes les possibilités de Reflexions sont parfaitement gardées. Si l'on prend exemple sur un type liste générique, en Java tu pourras déterminer à l'exécution qu'une liste est une liste, mais pas plus, tu ne peux pas savoir que c'est une liste de int ou de bool. En C# tu peux récupérer le vrai type, créer une nouvelle instance avec un nouveau type à la volée, etc.

                Pour plus de détails sur les différences entre les generics en Java, C++ et C#, c'est par ici :
                http://www.artima.com/intv/generics.html(...)
                On y comprend clairement les limites des templates en C++ notamment.

                Il est clair que l'avantage de la solution Sun et de ne pas avoir à modifier l'implémentation des VM pour faire fonctionner son code... Mais celà risque de rendre la VM Java vite obsolète face aux concurrents, les spécifications officielles de la VM de l'ECMA (celle de Mono et Microsoft) a déjà plus évolué en 2 ans que celle de Java depuis sa création...

            • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

              Posté par  . Évalué à 2.

              C'est bien ce que je dis: ces MV ont été développées avec l'idée qu'elle seraient la cible de langages impératifs à objets. Qu'il y ait des raisons objectives n'est pas le problème. Je trouve juste qu'il faut arrêter le trip "machine virtuelle universelle" (est-ce un déplacement du bon vieux "langage universel"?). C'est absurde. Mieux vaut plusieurs MV effectives pour des paradigmes précis qu'une seule MV moyenne dans tous les cas.

              En l'occurrence, les MV pour Java et C# ne sont pas adaptées à la compilation des langages fonctionnels. Contrairement à ce que tu prétends, il ne s'agit pas juste de compiler vers du code itératif. Pour les langages fonctionnels, on utilise en général certaines techniques pour lesquelles on ne trouve pas de primitive adéquate dans les MV sus-citées, on est donc obligé de passer par des fonctions qui bouffent du temps CPU pour rien. La gestion de la mémoire dynamique est en particulier problématique. Y'a qu'à voir les difficultés pour compiler du OCaml ou du F# vers la MV C#.

              Encore une fois je ne critique pas ces MV en tant que telles, je dis juste qu'elles ne constituent pas la solution "universelle".

              • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

                Je suis totalement d'accord avec toi. Ce que je voulais dire c'est que Mono peut être une plateforme "universelle" pour être un point de convergence entre les API et leurs utilisateurs, le fait que la VM soit adaptée à plusieurs langages ne fait qu'aller dans ce sens sans tout faire bien évidemment (ce n'est effectivement pas la VM qui est universelle).

                Pour ce qui est des primitives qu'il manque dans la VM pour certaines catégories de langages, il faut se dire que les spécifs de L'ECMA ne sont pas du tout fermées et la VM peut donc très bien évoluer, notamment en rajoutant des primitives. Par contre je suis curieux de connaître les primitives qui n'existe pas et qui pose problème, je suis intéressé et je veux bien que tu m'aiguilles, j'ai jamais essayé de faire un compilo de langage fonctionnel alors bon...

                Pour l'exemple de OCaml, regarde du côté de Ocamil, qui semble bien plus prometteur que F# qui reste un rat de laboratoire... Si ça se trouve il va y avoir la même différence qu'entre Python.NET et IronPython... La VM de l'ECMA n'est pas prévu pour être utilisé avec un langage interprêter pourtant IronPython tourne plus vite que l'original... Comme quoi les préjugés...

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 2.

        > la communauté libre doit absolument en passer par Java pour cela

        Chaque développeur a son langage préféré. Décréter que Java doit être le langage du libre, ça n'a pas de sens. Si je veux démarrer un projet libre, j'utiliserai mon langage préféré. Si je veux me joindre à un projet existant, le fait qu'il soit dans un langage que je ne connais pas sera un frein important.

        Le libre encourage par sa nature la diversité. C'est pour ça que débattre d'une fusion entre KDE et Gnome, entre Qt et GTK+ .... c'est une perte de temps.

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

      on pourrait dire la même chose GNU/Linux et *BSD qui fondamentalement sont des logiciels et libres et des systèmes d'exploitation.....

      mais comme dans pas mal domaines/sujets, l'heterogénéité à ses avantages et ses inconvénients....

      M.

      • [^] # rad for the masses ?

        Posté par  . Évalué à 3.

        le RAD non de dieu !! (c pas un Troll)


        Inquiet le Brendan et a juste titre (à mon avis...)

        Aussi admettons que je sois convaincu par ses arguments -ce qui entre () est presque fait-
        Maintenant je suis un petit developpeur qui veut faire une appli. desktop assez rapidement sans -trop- me prendre
        la tête.
        je vais donc chercher un "mozilla toolkit" comprenez par là :
        un designer style RAD etc...

        Hors rien, nada !

        Bien sur que M$ me les brise, mais qu'est-ce qui à chaque fois a fait le succes de leurs outils de dev. ?
        MSVC = IDE a l'interface ultra-pratique
        VB = langage de m*** certe, mais succes planetaire (Linus n'a-t'il pas dit de VB que c'était THE killer-app ?)


        Mozilla ne propose rien de tout cela !


        Aujourd'hui sous Winsteack32, un programmeur sans trop d'experience peut constuire une fenetre en 2 click
        y'a Delphi, C++Builder, VB, wxWindows, tout l'IDE .NET qui arrive fort... mais y'a pas Mozilla !! (à mon grand regret)

        Oui il y a 2 ou 3 applis utilisant le moteur Mozilla et pas des moindres (ThunderBird, etc...) mais je parle
        toujours pour du RAD, RAD for the masses.

        Bon y'a Qt heureusement qui avec son QtDesigner est genial
        sinon y'a Gtk, mais Glade ca daube grave (saus sauf Linux)

        Aujourd'hui tu montres XUL... bon super et alors, faut que je me tape 6 lignes de codes pour placer un bouton !?
        what !???

        qu'est-ce que vous en pensez ?

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

      Pour ce faire il y a du boulot. Il faudrait déjà que le projet Mozilla arrive à séparer le moteur XUL de gecko, du moteur javascript,....
      Et par la suite de ne pas avoir besoin de Mozilla pour lancer une application :(

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 2.

        Ils auraient deja du le faire depuis des mois... Car devoir installer puis charger en memoire 2 gecko, 1 pour Firebird et 1 pour Thunderbird, c'est n'importe quoi.

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          Pas forcément.
          Un des grands avantages de Firefox et Thunderbird est leur aspect "pouf ça marche".

          Donne une archive pour Linux/Windows/MacOSX/BeOS/etc. de Firefox à n'importequel utilisateur, quelques clics plus tard il sera en train d'utiliser un rutilant navigateur qui lui apportera bonheur et félicité.

          Si par contre tu lui dit que pour profiter de Firefox il doit d'abord télécharger la lib bidule, la BD MIME chose ou que sais-je encore ça sera bien moins rigolo.

          La décomposition fine des logiciels en paquetages avec des dépendances c'est bien quand on a un bon OS qui gère bien ça (apt, urpmi, etc.) ET une bonne connexion à Internet. Sinon c'est l'enfer.

          BeOS le faisait il y a 20 ans !

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 2.

            Faire une grosse archive avec toute les libs dedans ca prend une ou deux heures.

            Séparer le code pour en faire des libs ca prend un ou deux mois....

            Enfin juste pour dire qu'une fois que c'est séparé c'est très facile à repackager ensemble donc je vois pas le problème. Une fois cassé ca ne peut etre que mieux.

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

            Posté par  . Évalué à 2.

            La décomposition fine des logiciels en paquetages avec des dépendances c'est bien quand on a un bon OS qui gère bien ça (apt, urpmi, etc.) ET une bonne connexion à Internet.

            Eh ? Je me demande si t'as déjà utilisé Windows. Rien n'empêche d'installer des bibliothèques partagées en même temps qu'une application donnée.

  • # Mozilla et OpenOffice fer de lance du libre ?

    Posté par  . Évalué à -3.

    Oui sans contexte Mozilla est le fer de lance du Logiciel Libre, car il est connu des informaticiens bien sûr mais aussi de plus en plus des non-informaticiens qui l'utilisent soit pour une question éthique, soit pour des raisons techniques (performances, paramétrages supplémentaires, fiabilité, ergonomie...). D'ailleurs, les sites qui ne sont pas compatibles ont quasiment disparu.

    "Mais où est passé le site qui les référençait:"
    http://w3blacklist.tuxfamily.org/list.php?lang=fr(...)


    Mozilla c'est le cheval de Troie de la forteresse M$, une fois adonner à Mozilla, pourquoi ne pas passer à OpenOffice, et pourquoi pas à Thunderbird, GIMP, Samba, SPIP, Apache etc.


    Mozilla et son p'tit frère Firefox est aujourd'hui reconnu comme le meilleur navigateur tant par les spécialistes que par le quidam.

    Bientôt les manques d'OpenOffice seront comblé -l'État français aux travers de ses universités devrait mettre la main à la pâte si nous le poussons un peu-

    Primo le dico français existe déjà :
    http://atilf.inalf.fr/(...)
    Il est libre, il suffit de l'intégrer dans OpenOffice

    Deuzio le dico des synonymes aussi:
    http://elsap1.unicaen.fr/cherches.html(...)
    Il est libre, il suffit de l'intégrer dans OpenOffice

    Alors qu'est-ce qu'on attend !

    Au fait Mozilla progresse! Déjà 10% !
    http://linuxfr.org/~lastnico/11562.html(...)

    • [^] # Re: Mozilla et OpenOffice fer de lance du libre ?

      Posté par  . Évalué à 1.

      Où tu as vu que le dico français et des synonimes étaient libres ? T'as une url pour les télécharger ?

    • [^] # Re: Mozilla et OpenOffice fer de lance du libre ?

      Posté par  . Évalué à 1.

      > Alors qu'est-ce qu'on attend !

      Qu'au lieu de nous sortir toujours les memes marketingneries tu nous codes ca en vitesse !

      Pour les université je vois pas vraiment ce qu'elles ont a foutre la dedans. C'est quoi ton obscession avec les universités ?

      • [^] # Mozilla et OpenOffice fer de lance du libre ?

        Posté par  . Évalué à 1.

        Les universités ne sont pas au service d'une entreprise particulière que je sache !

        Elles sont aux service de la communauté, c'est dans ce cadre là, qu'il pourrait être utile qu'elles mettent leurs savoirs -en l'occurence un dictionnaire de qualité pour l'université de Nancy et un dictionnaire des synonyme pour celle de Caen- à la disposition des développeurs d'OpenOffice.

        Dans ce cas elles permettraient à d'autres universités, établissements scolaires, collectivités, entreprises, etc, d'utiliser OpenOffice et d'économiser en licences propriétaires et ainsi de participer au bien de la communauté.

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

    mmmh, je vais encore me faire moinsser mais c'est pas grave, je vais me répeter :
    XUL n'est pas une alternative à XAML. A la rigueur, XAML correspond à Glade dans le monde Gnome. Les gens voit du XML et la génération d'interface et zou... c'est la même chose... ralala. Mais Brendan le dit lui même : on peut récuperer quelques trucs dans XUL : en gros la syntaxe XML (bref on garde rien de XUL dans ce contexte) et tout le reste est à faire.

    XAML n'est rien d'autre que l'utilisation du langage XML pour mapper n'importe quelle classe du framework .NET, bref, rien d'innovant, rien de breveté, rien de dérangeant en soit.

    Passons à la partie troll du sujet (bah oui quoi, faudrait pas l'oublier :) ) :
    "Pour cela, il faut mettre en commun les efforts, et présenter un front unifié et Libre basé sur des standards ouverts."
    Le problème, c'est que pour le moment, seul Mono est capable de rivaliser avec les techno de Microsoft, Mono étant la seule plateforme managée (y'a une VM et tout le toutim qui va avec) indépendante du langage (en tout cas facilement utilisable dans tous les langages, même s'ils ne ciblent pas directement la VM, parcqu'il existe évidemment des langages pas tellement adaptés, mais bon, IronPython en a calmé plus d'un sur des affirmations gratuites que tout le monde a repris a coeur joie parcque ca leur faisait plaisir d'y croire).
    Bref, Mono est libre, basé sur des standards ouverts (GPL+LPGL+X11+ECMA+ISO+absence de brevets sur toute la partie qui nous intéresse), c'est un projet qui a maintenant plus de 2 ans, bien avancé, et surtout qui commence à être utilisé, ne serait-ce que par Novell qui base tout ses développement "multiplateforme" dessus.

    Après si y'en a qui veulent encore réinventer la roue et perdre un temps précieux face à la concurrence, pourquoi pas. Mais c'est pas aussi simple que XUL, et c'est pour ça que MDI il veut intégrer Mono à Gnome.

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 3.

    Y'a un détail qui me chipote: il me semble que le chtit détail qu'est l'IDE est oublié... amha c'est une des raisons qui explique la relativement faible utilisation de XUL... Microsoft nous promet un longhorn "de la mort qui tue" (et visiblement ils sont en train de se rendre compte qu'ils n'auront pas le temps de tout faire), mais un autre gros projet dont on parle beaucoup chez microsoft pour le moment, c'est Whidbey (alias Visual Studio .NET 2005)... Qu'est ce qu'on a (aura) côté logiciel libre?

    Microsoft a toujours sorti sa série: techno/outil de dev/documentation de façon relativement cohérente... du côté de mozilla c'est moins évident: on a une techno très valable, supérieur à ce que ms offre sur de nombreux points (ouverture, respect des standards, etc...), côté outil de dev, c'est déjà moins évident et niveau documentation, ça dépend énormément des sujets... (comment par exemple, dans une application Windows intégré un contrôle d'affichage HTML utilisant gecko? avec IE c'est 4 clicks dans l'IDE qui va bien, avec mozilla, je cherche toujours un moyen déployable...).

    Amha l'IDE (et les outils de dev en général) est un facteur déterminant, ce n'est pas tout d'avoir la possibilité technique de réaliser telle ou telle chose, il faut aussi avoir l'outil qui va bien...

    Il faut aussi tenir compte du fait que longhorn est un OS complet pas seulement XAML, et visiblement d'après le blabla (relativement marketing) de microsoft, y'aura beaucoup d'autres choses: certaines sont nécessaire pour que XAML tourne bien (DCE par exemple), d'autre permettre de faire de XAML un technologie interdépendante avec le reste (WinFS, Indigo, ...).

    En bref, je rêve du jour ou y'aura un bon IDE pour toutes ces technologies...

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

      Posté par  . Évalué à 1.

      > Y'a un détail qui me chipote: il me semble que le chtit détail qu'est l'IDE est oublié...
      > amha c'est une des raisons qui explique la relativement faible utilisation de XUL

      Y a un plugin pour éclipse qui est prévu

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

      il me semble que le chtit détail qu'est l'IDE est oublié[...]Qu'est ce qu'on a (aura) côté logiciel libre?
      Emacs :-(

      avec IE c'est 4 clicks dans l'IDE qui va bien, avec mozilla, je cherche toujours un moyen déployable...).
      Il y a un controle COM gecko qui utilise la même interface (au sens programmation) que IE. Je crois même qu'il est installé avec Mozilla.

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 1.

        Il y a un controle COM gecko qui utilise la même interface (au sens programmation) que IE. Je crois même qu'il est installé avec Mozilla.

        C'est mon prob: le controle COM que j'ai trouvé essaie de se substitué à IE, ce qu'un particulier peut faire ("je veux pas IE, tout moz!") mais qui n'est pas envisageable dans l'installation d'un logiciel (parce que c'est global).

        De plus, l'un des avantages de se passer d'IE est de pouvoir éviter l'activex (qui n'est d'ailleurs absoluement pas portable), mais bon, visiblement mozilla n'a pas pour but de permettre ce genre d'utilisation... et je trouve cela dommage, mais surtout dangereux: microsoft fait du closed source (pas bien), mais offre une série de SDK qui vont bien pour utiliser leur techno (mieux, même si trop souvent, ils cachent certains détails)... j'aimerais voir plus cela dans le logiciel libre!

        Enfin bref, si qq a une expérience quelconque dans un "embedded gecko", ça m'intéresse...

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 1.

        Il y a un controle COM gecko qui utilise la même interface (au sens programmation) que IE. Je crois même qu'il est installé avec Mozilla.
        1. C'est bien gentil mais ça marche que sous windows... pour l'aspect multi-plateforme c'est pas le top.
        2. On as pas accès à tout ce que fait moz, seulement au plus petit dénominateur commun entre Moz et IE...

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

      Posté par  . Évalué à 0.

      avec IE c'est 4 clicks dans l'IDE qui va bien, avec mozilla, je cherche toujours un moyen déployable...).
      C'est effectivement pratique quand tu veux faire un outil vite fait ou pour montrer la "puissance" de ce genre d'outils et dire "Msdev c'est bien on developpe plus vite qu'avec emacs" mais de le cadre d'un vrai projet, generalement un simple editeur de texte + un outil de vesionning + une bonne doc remplissent les trois quarts des besoins. De plus le temps gagné avec ce genre d'outil est ridicule face au temps total. Donc AMA, ca ne sert a rien de perdre du temps la dessus, mieux vaut completer les docs, c'est plus utile.

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 3.

        C'est effectivement pratique quand tu veux faire un outil vite fait ou pour montrer la "puissance" de ce genre d'outils et dire "Msdev c'est bien on developpe plus vite qu'avec emacs" mais de le cadre d'un vrai projet, generalement un simple editeur de texte + un outil de vesionning + une bonne doc remplissent les trois quarts des besoins.

        Je ne suis pas d'accord sur ce point, dans tous les projets que j'ai vu et tout les projet auquel j'ai pris part (que ce soit professionnel ou loisir), un bon IDE est un outil très bénéfique...

        Mais, je suis d'accord avec toi: dire msdev rulez je drop un activex en 4 click n'est pas l'argument convainquant (mais je parlais d'intégrer mozilla à une app, pas d'IDE, d'ailleurs sous windows, pratiquement tout les IDE permettent d'intégrer l'activex d'IE à une application... il ne s'agit donc pas de msdev uniquement). Cependant, quand on parle d'IDE, on parle de completion syntaxique (réelle selon les classes des projets en cours, etc...) de compilation réellement incrémentale, de debugging réellement intégré, de gestion des dépendances, de browsing de code, etc...

        Les outils "classiques" (make, CVS, ...) montre d'ailleurs souvent leur limites : ils ont étés conçus pour être général (c'est leur force!), alors qu'en fait un outil dédié à un langage (ou une techno) est souvent beaucoup efficace (mais limité à ce langage/cette techno): regarde eclipse par exemple, c'est l'un des meilleurs IDE java existant... pourquoi? parce qu'il comprends le java, qu'il est réellement intégré, depuis l'aide à la saisie jusqu'au refactoring en passant par le debugging, etc... (quoi que perso, je trouve le debugging trop lent, mais bon...)

        De plus si tu regardes la tendance, on se dirige petit à petit vers des outils avec certains aspect des outils case, encore une fois le fait que ce soit intégré fait la différence (je modifie ma classe, le diagramme est changé immédiatement, pas besoin de recompiler/recréer/modifier à la main, etc... je fais du vrai refactoring, pas de search/replace basé sur une regexp plus ou moins bien torchée). Et ce sont des domaines peu couvert pas les outils "classique"

        Enfin, j'ajouterais quand même une note: je suis d'accord avec toi sur le fait que l'IDE ne soit pas tout (disons le quart des besoins restant ;), que trop de programmeur sachant faire click-click s'imagine être des gourous... un bon IDE a parfois le défaut de faire passer certaines choses pour trop simple et finalement génère plus de problèmes que de solutions (c'est le cas par exemple des form designer: pour une about box ou une boite d'option, c'est sympa, mais ça montre souvent ses limites sur des IHM complexes). Et si je dois choisir entre doc ou IDE, je préfère avoir de la doc, qu'un IDE permettant de jouer avec un framework non documenté... mais microsoft offre (tente d'offrir) les deux... je crois qu'il pourrait être intéressant d'y penser... (parce qu'en plus ça a en général bcp d'influence sur le framework...).

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          Je suis d'accord aussi que le manque d'un cliquodrome intégré est très pénalisant pour des domaines qui ne sont pas les grosses applis.
          Pour trois types d'utilisations, voire d'utilisateurs: les non-informaticiens qui ne sont pas complètement idiots, voire qui aiment faire leurs applis, voire ceuw qui n'ont pas d'informaticiens sous la main (et c'est beaucoup de gens!! A mon avis c'est assez énorme comme demande).
          Les maquettes.
          Et les applis jetables - petites applications ponctuelles, qui sont souvent là d'ailleurs pour pallier les oublis des grosses applis.
          Linus a dit que VB était une kiler-app? Bien vue. Il est bien ce ptit gars.

  • # XUL#

    Posté par  . Évalué à 5.

    XUL# est une librairie de rendu pour XUL, écrit pour Mono

    La librairie est écrit en C#, et pour le moment utilise XUL uniquement pour le rendu des widgets Gnome et GTK+.

    http://opensource.reptile.ca/project/XulSharp/(...)

    • [^] # Re: XUL#

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

      Et ben voilà le problème est résolu :)

      Seulement voilà, il est encore plus facile, AMHA, de faire une implémentation de XAML qui n'est que du mapping des classes .NET (element = classe, attribut = propriété de la classe, mapping des événements, etc) ... De plus ce sera beaucoup plus puissant car pas limité à XUL (on perd forcement une partie de la puissance de GTK en passant par une couche d'API supplémentaire), et surtout le programmeur n'aura pas a apprendre un enième API différent... Mono (et la techno .NET) offre ce formidable avantage de proposer le même API pour tous, de manière transparente...

      De plus la documentation n'en sera que plus aisée à rédiger : regardez la documentation à votre disposition pour programmer avec Mono, on en trouve beaucoup plus qu'en lisant celle de XUL... Pourquoi ? Parcque Mono a un API proche de celui de Microsoft pour la partie normalisée, et "copié" sur les API GTK pour GTK#... C'est ce qui fait aussi la force d'une techno, c'est l'ensemble de la documentation et des ressources qui vont avec ...

      Evidemment on pourra reprocher le fait que beaucoup de ressources pour mono sont directement issu de Microsoft, mais bon, la documentation c'est au moins quelque chose qu'ils fournissent gratuitement, sans aucune restriction, à tous, et dans de nombreuses langues... Microsoft contribuerait à sa façon au développement communautaire :) Bon ok, j'arrête de triper.

      • [^] # Re: XUL#

        Posté par  . Évalué à 1.

        > il est encore plus facile, AMHA, de faire une implémentation de XAML qui n'est que du mapping des classes .NET

        C# ne pose pas de problème pour le logiciel libre. Ce n'est pas le cas avec .NET.

        Je pense qu'il ne faut pas se focaliser sur la "facilité" pour faire un équivalent d'XAML.
        Si une bonne proposition de plateforme (rien à voir avec le language) logiciel libre est faite et que ses qualités sont reconnues de tous, ça ira très vite.

        • [^] # Re: XUL#

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

          Je ne parle pas du C#, je parle de Mono, et de .NET par abus de langage, c'est vrai, pour représenter le framework. Mais dans le contexte je parle bien sûr de l'ensemble de l'API Mono qui est en partie basé sur les spécifications de l'ECMA, et en partie sous licence (L)GPL pour le reste (GTK#, Mozilla#, Glade#, etc), bref, aucun problème pour le logiciel libre. Ce que je voulais dire c'est qu'il est très facile d'appliquer le même principe (con mais tellement simple et avantageux) que XAML pour Mono, ce qui limite l'utilisation pour moi de XUL#, et que effectivement le débat se situe évidemment plus bas, dans le choix de la plateforme comme tu le dis d'ailleur.

          Mais moi y'a une question que je me pose, c'est que chez mozilla ils ont l'air de vouloir se rapprocher de Gnome et éventuellement de Mono (qui tente déjà de flirter avec Gnome), mais quid de KDE ? N'auraient-ils eux non plus pas le droit à un environnement intégré basé sur une nouvelle plateforme ?

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 1.

    A votre avis, l'engagement d'IBM dans ce genre d'affaires pourrait-il être envisageable ?

    IBM demande à faire passer Java en OpenSource, contribue à Mozilla et Gnome...

    Je me demande ce que cela pourrait faire, et même si c'est envisageable...

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 2.

    Je vais encore me faire moinsser mais franchement vous etes jamais content :

    Avant, le libre était écrasé, et vous étiez mécontent parce que les grosses boites le dénigraient...

    Maintenant, le libre est reconnu, voire privilégié dans certains domaines (web par ex, aussi bien coté client que servers), les grosses boites adoptent des politiques très proches du libre (Sun avec OOo, IBM avec Eclipse, etc...) et vous etes encore pas content parce que tt ce que ces boites releasent n'est pas forcément 100% libre sous GPL...

    Faut pas réver, le commercial est nécessaire et il faut plutot viser une collaboration plutot qu'un affrontement...parce que aller au clash, c risquer des campagnes genre ce que fait MS en ce moment, mais en bcp plus méchant (celle de MS fait plutot rire, mais bon)...

    Faut bien voir que ceux qui dirigent le business ce sont les entreprises clientes...et que le libre n'a pas encore de solutions à tous leurs problèmes...(info décisionnelle, BDD haute charge, ERP, etc...) qui sont pourtant des besoins centraux de l'entreprise...

    Par ailleurs, java plait aux entreprises, et les fac ne s'y trompent pas : aujourd'hui un ingé ne fait presque plus de C/C++, mais fait du java et du C# : les temps changent...

    Ca me décourage de lire LinuxFR...on voit que des prises de tete sur quoi est 100% libre, sans se demander quelle était la finalité...

    Je trouve légitime que des programmeurs veuillent se faire rétribuer pour leur travail...soit en demandant de l'argent, soit en veillant à ce que son nom soit attaché au code...ce que la GPL ne permet pas (et qu'on arrete l'hypocrysie : qui irait payer pour un soft qu'on peut avoir gratuitement ? qu'on fasse payer le support, le packaging je veux bien, c possible parce qu'il y a une valeur ajoutée...mais bon, une bonne ligne internet, une imprimante pour le manuel, et hop, en même pas une heure on peut refabriquer le package de n'importe quelle distro...pour pas 1€...donc c pas un modèle économique super viable la vente de packaging...

    • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

      «Faut pas réver, le commercial est nécessaire»

      Attention, tu n'as pas compris de quoi on parle, alors forcément que tu t'énnerves. Le libre peut être commercial, et le non-libre peut être gratuit, ce sont deux choses qui n'ont pas de rapport. Si tu pars du principe que libre == gratuit et non-libre == payant, forcément il y a un (gros) malentendu.

      «on voit que des prises de tete sur quoi est 100% libre, sans se demander quelle était la finalité...»

      Ne pas s'interroger sur l'ouverture du code, c'est raisonner à court terme... ce que tu sembles pourtant "nous" reprocher. Du code ouvert et libre, ça signifie que quoi qu'il arrive, on pourra toujours apporter des modifications aux produits qu'on a acheté, c'est un aspect qui devrait être au coeur des préoccupations des entreprises.

      Du code fermé, par contre, c'est se rendre dépendant d'une entreprise. Si elle survit tant mieux, sinon il faut acheter un nouveau produit.

      Voilà une raison OP (Orientée Pognon) de préférer des produits libres à des produits propriétaires. Histoire de (tenter de) te convaincre que les gens qui s'intéressent à l'aspect libre ne sont pas tous des crétins profonds.

      «Je trouve légitime que des programmeurs veuillent se faire rétribuer pour leur travail...soit en demandant de l'argent, soit en veillant à ce que son nom soit attaché au code...ce que la GPL ne permet pas»

      L'as-tu lue, la GPL ? Ok, tu n'es pas d'accord sur le fait que l'on peut être payé et développer du GPL, c'est ton droit de nier les exemples existant. Mais sur le deuxième point, c'est n'importe quoi. Tu confonds allègrement logiciel libre et domaine public. La GPL conserve évidemment le copyright des auteurs sur leur code.

      Tu n'as pas l'impression que le nom des développeurs est associé à leur code ? Bien, je suis sûr que tu peux citer de mémoire, comme beaucoup de gens ici, le nom de quelques développeurs du noyau Linux. Peux-tu faire de même pour les développeurs de Windows ?

      Autres gens connus, le développeur d'Emacs, celui de Python, celui de Perl. Connais-tu des développeurs de Visual Basic, d'ASP, de Visual Studio ? (exemples pris au hasard, de logiciels propriétaires en général)

      • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

        Posté par  . Évalué à 2.

        Je trouve ça pas mal comme mode de programmation.
        Après la POO (Programmation Orientée Objet) et la POA (Programmation Orientée Aspect)
        voilà la POP (Programmation Orientée Pognon) ce nouveau mode est très lié à l'aspect marketing et commercial de l'outil développé.

        Je me suis fais ma définition, je suis content, je vais me recoucher.

        • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

          Posté par  . Évalué à 1.

          Toi non plus ne sait pas lire mais c pas grave...

          je ne pars pas du principe que libre = gratuit et GPL = payant...

          mais je t'en prie cite moi des exemples de grosses boites ayant des produits sous GPL et qui ne vie que grave à la vente de ces produits, et pas grace à la vente du support...(donc ca exclue mandrakesoft par exemple...)...

          par ailleurs ok java c pas libre, mais vu que le compilo t'es fourni, si sun fait faillite demain, explique moi ce qui t'empeche de continuer à utiliser ton compilo...voir d'en créer un from scratch étant donné que les specs de java sont publiques...

          pour les programmeurs, t de mauvaise foi : évidement, les chefs de projets sont connus...je me souviens que récemment, y'a eu des débats sur un licence qui obligeait qu'on donne la liste des programmeurs ayant contribué, et que ca avait été jugé non libre...donc non...

          par ailleurs les produits ms c pas forcément le meilleur exemple, y'en a plein le MSDN, et via les easters eggs de programmes, on peut les voir...

          mais je discute plus...espérez un monde 100% libre et mal organisé, et on se reverra dans 15 ans pour en parler...

          • [^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

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

            «je ne pars pas du principe que libre = gratuit et GPL = payant...»

            Non, mais tu raisonnes comme si libre == gratuit, et non-libre == payant. Même si tu es conscient de la différence, tu suis ton raisonnement comme si c'était le cas.

            «mais je t'en prie cite moi des exemples de grosses boites ayant des produits sous GPL et qui ne vie que grave à la vente de ces produits»

            Ça fait beaucoup de contraintes concernant les exemples que je peux te donner, dis moi. Moi j'ai des exemples (et encore, il me faudrait du temps pour les retrouver vu que ce n'est pas mon domaine) de boîtes pas grosses, qui vendent des logiciels spécialisés sous GPL, qui ne sont pas en téléchargement sur leur site, et qui sont plutôt chers.

            Si ça te convient comme type d'exemples, je ferai l'effort de rechercher, je sais que j'en avais trouvé une suite à un message sur le newsgroup de "debats" sur linux :-)

            Ceci dit, je serais tenté de dire que si une boîte n'arrive pas à vivre uniquement de la vente de produits, il y a deux manières de voir le problème:

            - soit le libre n'est pas quelque chose que les clients devraient vouloir.
            - soit les boîtes doivent s'adapter à la demande et trouver un moyen de vivre tout en proposant ce que les clients veulent. Celles qui ne savent pas s'adapter disparaissent. C'est très ultra-libéral comme point de vue, mais je préfère encore ça à la première solution.

            «vu que le compilo t'es fourni, si sun fait faillite demain, explique moi ce qui t'empeche de continuer à utiliser ton compilo»

            Je n'ai jamais prétendu que si la boîte coule tu ne peux plus utiliser ses produits. Si MS coule tu peux toujours continuer à utiliser Word. Par contre les produits n'évolueront plus, ce qui fait qu'en quelques années ils seront devenus obsolètes.

            «voir d'en créer un from scratch étant donné que les specs de java sont publiques...»

            Ah ben voilà, quand un soft n'est pas libre, on peut être ammené à le redévelopper parce qu'on n'a pas les sources. Super. Si j'étais un décideur pressé, je ne prendrais certainement pas ce risque.

            «pour les programmeurs, t de mauvaise foi»

            Dis donc c'est un peu facile, quand la réponse ne te plait pas c'est qu'on est de mauvaise foi ?

            Tu dis qu'avec le libre le nom des programmeurs n'est pas associé à leur code, alors que c'est justement avec le propriétaire que c'est le cas. Je me contentais de comparer le nombre de développeur qu'on connaissait à la fois dans le libre et le proprio. Bien évidemment qu'on ne connaît pas tous les développeurs. Par contre dans tout projet correctement géré on peut retrouver leurs noms.

            «par ailleurs les produits ms c pas forcément le meilleur exemple, y'en a plein le MSDN, et via les easters eggs de programmes, on peut les voir...»

            Si j'avais été de mauvaise foi comme tu dis, j'aurais peut-être choisi le "meilleur exemple" pour défendre mon point de vue. Mais je ne met pas en question le fait qu'on puisse retrouver le nom des développeurs, juste le fait que quand on fait du libre on a plus de chances d'etre connu du public.

            «espérez un monde 100% libre et mal organisé»

            Tu serais pas un tout petit peu manichéen des fois ?

            Toi ton point de vue c'est que tout le libre devrait utiliser une solution propriétaire, et quand on n'est pas d'accord, c'est qu'on espère l'extinction totale du propriétaire dans l'univers ? Wahou :-)

            Moi j'estime juste que pour mes besoins, et ceux d'une entreprise si jamais j'en ai la charge un jour, le propriétaire n'est pas satisfaisant. Du point de vue du client. Que les producteurs se débrouillent comme ils le désirent pour me procurer les produits que je désire acheter, ce n'est pas mon boulot.

            PS: je tiens à m'excuser auprès de mes lecteurs pour cet argumentaire Orienté Pognon, mais c'est sur ce terrain que le monsieur a voulu discuter, alors..

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 0.

    C'est en tout cas un très bon signe: l'équipe Mozilla se réveille et veut promouvoir son (excellente) plate-forme, et ce en cherchant à s'associer avec d'autres projets d'envergure comme GNOME. Ce ne sont pour l'instant que de bonnes intentions, mais elles méritent d'être soutenues. Il est vrai que d'un côté XUL + Javascript, de l'autre libGlade + Python, il y a quelques similitudes dans la démarche adoptée pour construire rapidement des applications "lourdes".

    Pour info, le livre de Nigel Mc Farlane "Rapid application development with Mozilla" est librement téléchargeable:
    http://www.informit.com/content/downloads/perens/0131423436_pdf.zip(...)

    Je me pose quand même une question: qu'en est il du port de Mozilla sous MultiDeskOS?

  • # Standardisé par qui ?

    Posté par  . Évalué à 1.

    "Pour cela, il faut mettre en commun les efforts, et présenter un front unifié et Libre basé sur des standards ouverts."

    C'est un standard, XUL ? Standardisé par qui ?

    • [^] # Re: Standardisé par qui ?

      Posté par  . Évalué à 1.

      Pas de réponse, dommage.

      Il semblerait que la communauté de libre ait un problème de vocabulaire. Il y a une différence entre formats ouverts et formats standardisés.

      • [^] # Re: Standardisé par qui ?

        Posté par  . Évalué à 2.

        je crois que mozo a tenté de standardié xul, mais ça a été refusé.
        Mais bon sur un domaine un peu nouveau, cest normal qu'auncun standard ne soit en place. Ou peut-être signifait-il que xml était standardisé

  • # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn

    Posté par  . Évalué à 1.

    Je viens de tester la construction d'interface un XUL, c'est génial la simplicité de fabrication comparable à du web avec toutes les fonctionnalité d'une interface client lourd.

    Avec un bris de SOAP pour déporter les business logic sur un serveur d'appli est c'est le pied.

Suivre le flux des commentaires

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