sylware a écrit 284 commentaires

Et tu m'expliques pourquoi Java et .NET ne serait pas des assemblages cohérents ? Ils ont été conçus justement pour être cohérents !

La plateforme python est cohérente, la plateforme perl avec leur système CPAM est cohérente, la plateforme erlang est cohérente etc etc... et il est tout à fait possible d'assembler des solutions hétérogènes qui forment un tout cohérent.

Tout comme avec une plateforme Java, qui elle est déjà normalisée, tu choisies les briques qui t'intéresse, de la simple VM embarquée au serveur d'application, du composant sous licence libre au composant proprio, et tu gardes une cohérence technique de A à Z.

Quand c'est une norme, ça veut dire que c'est passé par un organisme de normalisation. Ces organismes sont nombreux. Certains ont plus ou moins bonne réputation. Dernièrement je traîne pas mal sur le site de l'organisme OASIS qui a normalisé le format open document et toujours sur le même site je m'intéresse à la norme docbook. Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java? Ça me trouble car normé avec un degré de rigueur correcte des plateformes gigantesques et tentaculaires comme java qui évolue assez vite donc rendrait la norme vite obsolète me semble utopique.

Oué elle était facile, mais pas si dénuet d'intérêt : Unix à la base c'est du 100% proprio, si on t'écoute on aurait dû garder la philosophie ;)

J'écoutais un discours de RMS qui rappellait qu'a la base, les logiciels étaient libres. C'est en train de revenir, et c'est tant mieux! Les bonnes choses reviennent toujours. Pour en revenir à la philosophie d'unix et autre motto bourrés de bon sens... http://en.wikipedia.org/wiki/Unix_philosophy et http://en.wikipedia.org/wiki/Live_free_or_die#Use_in_Unix

Oué mais c'est totalement indépendant de ton appli, j'y suis pour rien. Et si ca arrive trop souvent, je peux justement changer facilement d'OS vers un OS moins troué grâce à l'indépendance que me procure la VM ;-)

Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr! Portez une VM et tout son framework sur un OS prétendu "moins troué". Quelles jolies galipettes! (Cf J2ME). Mettre au point et maintenir des combinaisons de HARD+OS c'est déjà pas forcément facile, alors les combinaisons HARD+OS+VM... euh... non merci.

Oué, si tu veux. Sauf que globalement t'es bien obligé de respecter les libs que t'utilises, tu t'amuses pas à utiliser un GC dans ton coin, une autre lib utilise le sien, l'autre fait des malloc à la main et libère, l'autre fait des malloc mais sous-entend que c'est à l'utilisateur de libérer, enfin un vrai foutoir d'intégration qui se finit en fuites mémoires. (attention je dis pas qu'avec les VM c'est impossible, juste que le modèle mémoire est normalisé).

Tu n'as besoin de respecter le GC que là où tu as en besoin, ailleurs, ça serait du gâchis de ressources. Perso, je n'aime pas beaucoup les garbage collector, ce gâchis et cette perte de contrôle.... beurk! Mais, j'essayerais un jour de coder quelquechose en C++ avec un garbage collector. Lorsque j'ai travaillé en téléphonie mobile, pour "vendre super sécure"(TM), un composant de la solution n'avait tout bonnement pas d'allocation mémoire dynamique, tout était statiquement alloué à la compilation et préparé aux petits oignons. Mais seulement le composant exposé, les autres était pénards et pouvait utiliser la politique de gestion mémoire qu'ils souhaitaient.

Oué ca c'est dans le meilleur des mondes... Y'a 2 approches :
- "la gestion mémoire est tellement importante que je préfères ne pas laisser la machine s'en occuper"
- "la gestion mémoire est tellement importante que je préfères ne pas laisser un humain s'en occuper"
Choisi celle que tu veux moi c'est tout vu :-)

Pourquoi exclusivement machine ou humain? La meilleurs solution n'est certainement pas l'une ou l'autre, ça dépend de ce que tu as besoin de faire et des ressources dont tu disposes. En aucun cas l'un ou l'autre n'est magique: "les humains sont tous de nullards" et "les ordinateurs sont super intelligents"? Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.

Tu vas rire, mais les plateformes comme Java ou .NET/Mono peuvent accueillir de nouveaux langages, même que si tu google un peu Erlang + Java ...

Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime. Si j'ai bien compris la VM parrot à l'intention de devenir la VM universelle. Après une bref recherche sur google j'ai trouvé ça: http://www.sics.se/~joe/ericsson/du98024.html Bon... il faut avouer que les benchs.... ça se détournent... à tel point que les benchs hurlés partout sur le net valent encore quelque chose...

Ben justement, je préfère amplement avoir une plateforme cohérente de A à Z, de la couche d'accès aux données aux clients lourds en passant par le serveur web, pour justement éviter la complexité et la lourdeur de ponts intermédiaires artisanaux qui engendre de nombreux problèmes techniques.

Moi aussi, je préfère largement avoir une plateforme cohérente qui répondent au besoin métier du clients. Et je me passe très bien de VM qui est une dépendance qui ne fait qu'alourdir ma solution par l'ajout d'une quantité de code loin d'être négligeable qu'il va falloir gérer et maintenir.

Je préfères encore une fois faire confiance à la VM qui n'a sûrement pas été codée avec les pieds qu'à moi même pour réinventer la roue ;)

"sûrement"? Si ça te suffit... :D "L'OS de MS est le meilleur du monde(TM) car c'est la plus grosse boîte du monde et que donc par définition il ne peuvent pas faire de la mBIP!" te suffit également? Je suis désolé mais ça n'est pas suffisant: Ce que je vois, c'est un mastodonte de code à gérer et à maintenir qui duplique les services qui me sont offerts par mon OS préféré et ses libs de base, donc si je peux m'en passer je m'en passe. Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.

Une plateforme comme Mono (je parle de ce que je connais), c'est le même ordre de grandeur en nombre de lignes de code...

...dans le pb de dépendance vis-à-vis de MS, comme JAVA de Sun? C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C, combien de ligne de code C pour la VM de Mono? Erlang 41000 pour la VM tu disais? Il faudrait aussi voir du côté de la VM parrot, de ruby, de perl et des autres.

Le problème ne vient pas des composants en soit (qui sont souvent auditer de manière individuel), les problèmes viennent de l'assemblage "sur-mesure" que tu créés, qui est nouveau, et apporte une complexité et des risques supplémentaires.

En général, il n'y a pas tant de libs que ça, et souvent les combinatoires sont les mêmes. Les risques et les efforts de maintenance sont proportionnels à la quantité de code modulé par sa complexité. Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.

C'est passionnant!
Oué bah j'espère que t'as la chance de ne pas faire la maintenance :)

J'ai fait de la maintenance sur des applications complexes tapant les millions de lignes: un cauchemar, C'était plus des amas de rustines et de code tordu pour compenser le design malfoutu et les bugs des "produits"(TM) de boîtes qui "certifiait"(TM) et "supportait"(TM) ta mère ton oncle et la paix dans le monde(TM)... ct pas passionnant plutôt irritant et dévalorisant, par contre tous les projets que j'ai fait sur du libre dans une optique unix, ct passionnant et intéressant.

Oué, sa c'était la philosophie d'il y a 30 ans. Heuresement les mentalités évoluent.
KDE ou GNOME sont des grosses plateformes qui dans la philosophie Unix ne devrait pas exister, rappel toi, normalement tous les softs devraient être des jolis exécutables qui discutent avec des pipes...

Les mentalité changent, des bonnes recettes restent et on refait les mêmes erreurs...
KDE et GNOME sont des assemblages cohérents de libs. gnome va essayer de dropper corba car bien trop complexe pour les tâches d'un desktop (overkill). En effet, un des fondateurs a fait ce mauvais choix, mais avec lui c'est en train de devenir une habitude. Le but de ces projets est de fournir le service "desktop" pour utilisateur normal. Le service desktop est indépendant de xorg qui gère l'affichage. KDE,gnome et d'autres se fédèrent autour de freedesktop pour que la miriades d'éléments composant l'offre des desktops puissent intéropérer malgré leur différence dans les choix d'implémentation. Si ce projet réussi, à terme on pourra "composer" un desktop cohérent avec un certain degré de liberté... rien de plus normal pour du libre et dans le cadre de la philosophie unix.

Je suis sûr un site consacré à GNU Linux, et GNU is NOT Unix ! :-p

Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.

C'est bon merci, je suis pas con, j'ai même argumenté derrière en expliquant pourquoi je préfère largement que les services les plus courants qui nécessite d'être codé avec un langage de bas niveau (gestion mémoire toussa) le soit une fois pour toute dans la VM, codée par des personnes compétentes, et que le jour où une faille de sécu est corrigée, toutes les applis qui tournent dessus en profite !

Ta VM tourne un OS. Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise. Déléguer la gestion mémoire, ou gérer plus finement sa gestion mémoire, c'est un choix (du moins tant qu'on te le laisse... huhu...). Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux. Mais bon, le meilleur compromis seraient que les codeurs s'intéresse un peu plus à la sécu pour coder au mieux "secure" tout en conservant une gestion fine de leur besoin de mémoire.

T'es incorrigible, t'es toujours pareil, dès que tu cherches un atout, tu le cherche dans une autre brique. Evidemment que Erlang permet de faire du réparti, c'est fait pour. Mais en attendant Erlang ne propose pas une plateforme aussi complète que Java ou .NET.

On m'a dit qu'Erlang était conçu dans le but de faire de l'informatique réparti pour les télécom et de le faire bien, et que pour pouvoir faire au mieux, il possédait une sémantique/syntax adaptée, ce que les autres langages n'offrent pas (tant pis pour eux, ils n'auront pas le meilleur de ce monde).

Ah oui, y'a la vraie gestion mémoire et la fausse... En attendant ton OS favori il a vraiment du mal à gérer les débordement tampons et les fuites mémoires. Moi je fais confiance au modèle de sécurité des VM modernes et à leur GC bien plus sécurisés que mes malloc.

Je parlais de la mémoire (allocation de page physique), pas de la gestion mémoire... pas grave, ct ambigüe. Sinon, je te renvois au paragraphe au dessus concernant la sécurité de la VM. Une règle général en sécurité: plus tu as de code, modulé par sa complexité, plus tu as de risques d'avoir des failles de sécurité. Donc pour réduire les risques de failles, j'aurais tendance à virer la VM (beaucoup de code complexe), simplifier au maximum le code et me concentrer sur les failles de l'OS.

Je voulais te montrer que dans la vraie vie avec des vraies applis, on ne peut se contenter de l'interpréteur Python de 5000 lignes, et que Zope fait plus de 5000 lignes pour être un minimum performant.

Tout ce je sais, c'est que j'ai pas sortie l'énormité que Zope avait 5000 lignes de code. Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles. Le C est là pour la performance et/ou abstaire les services de l'OS/libs de base plus "pythoniquement". En effet, dans certains cas, abstraire ces derniers services en C et bien plus efficace que de le faire en python (qu'avec des appels directs aux fonctions des services de bases) ou que d'alourdir et complexifier l'interpréteur en y ajoutant de nouveaux opcodes.

Oué et je joue au mécano ? Comment j'assemble tout ca ? Qui va s'assurer que mon assemblage ne va pas être bourré de trous de sécu ? Nan parcque moi je suis un simple développeur/Architecte, je suis pas un guru de la sécu.
Et puis bon, qui va résoudre tous mes problèmes d'intégration et de déploiement, nan parcque déployer une appli dont le coeur est codé en C/C++, le serveur d'application en erlang, les pages web en PHP, les clients lourds en Qt et les scripts en Perl, merci ! T'es à 15000 km des réalités du développement de grosses solutions toi c'est pas possible.

En général, tu as des entreprises qui offrent des audit de sécurité et qui peuvent fournir du conseil en sécu. Les composants exposés à des attaques réelles pourront être audités et le développement pourra être assisté par un consultant en sécu. Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance (qui continue de se propager) de manière noble, cad pas par des campagnes de pub/com. Perso, les applications les plus gourmandes dont j'ai entendu parlées ont été re-écrites en langage machines. Cela dit, les solutions les plus hétérogènes que j'ai pu voir étaient des solutions qui avait vieilli sur des années, récupérant diverses technologies de divers âges au fur et à mesure de leur évolution fonctionnelle. C'est passionnant!

Je sais ce genre de joute tribal est lamentable et j'en suis le premier à m'en plaindre... car c'est en fait ce que je voulais démontrer. Je n'ai pas à être convaincu des choix technologiques de A ou B. J'ai fait les miens. Ce qui est très dommage ce sont les entristes de tous les bords qui sillonnent les points névralgiques du net pour le LL, dont linuxfr, pour les polluer y vomissant leur diatribes ou leur campagne de comm/marketing.

CQFD

Pour en revenir à nuxeo, ce qui va suivre est une question fermée, la réponse est oui ou non.


Est-ce que le nouveau CPS de nuxeo en java tournera sur des JVM libres?

Moi je voulais justement te montrer qu'il y a des plateformes qui sont homogènes, et qui prennent le meilleur de chaque monde.

Tu devrais quitter le monde unix, car tu n'as pas très bien compris sa philosophie... :D Mais tu as le droit de n'être pas d'accord en prônant exactement le contraire sur un site consacré à un des unix les plus populaires! Les framework homogènes font des compromis, et les compromis riment avec le sacrifice du meilleur de certains monde.

C'est écrit en quoi une VM? Tu peux me le rappeler?
Et donc ? une VM est écrite une seule fois, elle est largement testée et éprouvée, alors que le développeur créer souvent du code neuf pour une nouvelle appli, et c'est là qu'il peut laisser traîner pleins de trou de sécu. Sans parler du fait que ce n'est généralement pas du tout les même développeurs avec les mêmes compétences qui développent les applis et la VM.

Bah, tu ne veux pas répondre... et bien je vais le faire à ta place une VM s'est écrit en langage de bas niveau et comme tu l'as très bien fait remarquer:

..alors que c'est une des failles les plus répandues dans les langages bas niveau

Bon, je te dis ça, hein histoire que tu ne fasses pas trop rigoler les gars en sécu. Tu as le même discours que les Crosofteux qu'il y avait à la Black Hat: "super sécure, éprouvé etc etc...".

RE: rappel toi, j'ai argumenté en montrant que même dans le libre on en a besoin, que le C/C++ c'est portable seulement quand on le veut bien, que pour le déploiement c'est pas naz, et pour créer des applications réparties qui tournent sur des OS différents c'est encore plus naz.

re:Erlang? Assure toi d'avoir faire une recherche sur http://freshmeat.net et http://www.google.com avant de réduire le libre au C/C++. Tiens en dépêche tu as un serveur pour faire du JABBER/XMPP en répartie.

Ah, les threads sont moins bien éprouvée dans l'OS?
Désolé, j'ai mélangé 2 exemples, je voulais dans un premier temps parler de la gestion mémoire, et du fait que beaucoup de programmeurs C/C++ réinventait la roue plutôt que d'utiliser une implémentation éprouvée, et je suis ensuite parti sur le problème des threads pour montrer qu'ils étaient bien différents d'une plateforme à l'autre, et qu'à ce titre il fallait une couche d'abstraction indispensable.

Le gestion de la mémoire(la vraie), tu crois que c'est pas dépendant de l'OS tout ça... Et oui sur les threads... re :D

Ben pourtant les VM y arrive...

Oh quelle est belle! Voir para précédent.

Tu crois que Zope est "léger" et fait 5000 lignes de code ?

Zope est une VM? Jt persuadé d'avoir parlé de l'interpréteur de python.

Figure toi qu'à une époque Java était interprété, et qu'il y avait sûrement des implémentations très légères, notamment pour l'embarqué, mais personne n'a vu l'intérêt de rester sur ces modèles, c'était plus une limitation dû à un manque de connaissances dans le domaine. Y'a plus que toi pour trouver ca bien.

Et le J2ME "éprouvé et testé"TM fut inventé....

Oué et on retrouve la poutre et les briques derrière ta porte :) T'es gentil mais là tu me proposes pas la solution, tu me proposes de la faire moi même ma solution. Moi j'ai pas forcement envie de réinventer la roue tous les jours tu vois.

Et bien, en fonction de tes besoins tu fais ton "shopping" en choississant les libs/soft qui te conviennent en fonction des paramètres que tu cherches: robustesse, sécu, vitesse, features, licence, RAD etc ... En général, les roues de base viennent toujours d'un petit nombre de libs/soft. Pas besoin de plus la plupart du temps.

Je pense qu'une des meilleurs VM qui soit est linux. Du hard et boom linux dessus. Inutile de s'encombrer d'une VM additionnelle qui va ajouter des tonnes de code supplémentaire à prendre en compte et à gérer. Gardons les choses simples. En terme de langage piocher dans C/C++/python/ruby/perl/erlang etc... en fonction des caractéristiques voulues de la solution cliente avec les libs/soft qui vont bien. Complètement dans l'esprit unix.

Tu réponds tjs à coté de la plaque. Ce ne sont pas les briques qui sont inmaintanables , c'est leur assemblage.

C'est vrai rien ne marche ensemble.Complètement inmaintenable. Tu en as d'autres comme ça?

Tu as raison, des centaines de developpeurs produisent des LL sur la plateformes JEE? Il y des serveurs d'application : Geronimo, Jboss, Jonas, des librairies en pagaille, des IDEs , des applis desktops. Mais toi tu sais mieux que tout ce petit monde. Tu es un vrai sage.

JEE n'est pas libre, ce petit monde fait des LL dans un framework non libre. Faire du LL sur des OS proprios c'est pareil. Bien sûr, pour rester dans l'esprit des LL, ils s'évertuent à faire tourner leurs softs sur des VMs libres, non? C'est ce que va faire nuxeo?

Je croyais qu'on trouvait tout en mieux dans le "pure" libre.Alors comment tu fais pour faire un ihm potable sur un backend erlang en distribué. Tu mets un peu de TCL/Tk en client lourd du PHP en léger , qui passe par un connection SSH, avec un serveur Apache en frontend. Ca doit pas fuir de toute part ca. Au niveau du deploiement ca doit être simplissime. Pis va falloir les dieux du dev
pour maîtriser le bouzin. Les J2EE lead architect, c'est des enfants de choeur à coté.

http://erlgtk.sourceforge.net/ ... Tu n'aimes pas le "pure" libre? Alors je te conseille l'adresse suivante où tu trouveras pleins de copains (plus qu'ici à priori, car on aime bien le libre nous) http://msdn.microsoft.com

Le reste est un délire incompréhensible.
T'es vraiment despérant, je jettes l'éponge

Ah dsl, j'aurais p'tet du descendre de mon nuage de sage pour me mettre à ton niveau? Crois-moi, je ne jette pas l'éponge moi, je veux vous sauvez, je vous aime!

Utilisez C/C++/Python/Ruby/erlang/linux etc... Sauvez votre âme.

COmment vas-tu tout à coup offrir l'introspection et la sécurité d'un code derrière une VM à une appli C++ ? Nan parcque ca serait très intéressant quand même :)

Je ne parlais de la killer feature d'instrospection que tu peux faire en python et en ruby si tu en trouves l'utilité, je te parlais de combiner C/C++python/ruby pour faire des applications hétérogènes.

Oui parcque justement ces VM ont été conçus dans ce but de sécurité, S'il y a une faille, elle est dans la VM, mais c'est plus facile de patcher une VM qu'un hardware :) Evidemment qu'il n'y a pas de risque 0, mais il faut bien reconnaître que ce n'est pas tous les jours que tu vois un problème de débordement de tampon dans une appli écrite en Java/.NET, alors que c'est une des failles les plus répendues dans les langages bas niveau.

C'est écrit en quoi une VM? Tu peux me le rappeler?

? Le but est d'abstraire les fonctionnalités de l'OS, et je préfère 1000 fois une gestion des threads implémentée et éprouvée dans la VM, quitte à être redondante, que d'être obligé de m'adapter suivant l'OS à tous les types de thread. Evidemment, abstraire ca a un coût. Mais faut savoir ce qu'on veut, et pour la portabilité c'est indispensable. Donc de toute façon dans ta solution magique alternative, t'as forcement quelque chose de similaire.

Tiens tu remets le couvert avec ta portabilité. RE:la portabilité binaire avec des soft open source portables... bof. Ah, les threads sont moins bien éprouvée dans l'OS? Et les threads de ta VM c'est pas celles de ton OS par hasard. C'est une hard feature des OS le threading, tu ne peux pas d'abstraire du modèle et ordonnancement de threading des OS, sauf si tu as l'intention d'avoir des threads qui s'exécutent séquentiellement. Et puis le coût dont tu parles, si tu le considère pas trop élevé tant mieux pour toi, tu es riches, mais pour ma part c'est un no-go pour ce que ces plateformes m'apportent. En fait, on aurait du s'arrêter là: je considère que ces framework ne m'apportent rien à par des inconvénients, donc la dîme VM.... ahem... par contre je dis pas pour python,ruby par exemple qui sont vraiment plus simples vraiment dynamiques et ont un interpréteur poids plume comparé aux VM de tes framework... là, je pense être prêt à payer la taxe interpréteur.
Comme je l'ai dit:

un énorme tas de code compliqué redondant vis à vis du code de l'OS: arithmétique simple: plus de code=plus d'emm*****. La VM sert à rien, tu as du hard, tu met linux et tu te fais pas ch*** avec le paquet de code de la VM.Linux est une super VM. Tu verras.

Tu oublies que cette solution, moi je te dis "montre moi une autre maison", toi tu me dis : "tiens j'ai un tas des poutres, des briques, une baraque à frite, une tente, une friteuse, un meuble ikea en pièces détachées, des vis et une fourchette".

Allez... une analogie à 2 balles 30, fais-le toi-même, tu es grand: http://freshmeat.net ah... et c'est que le hall d'entrée (1 balle 2). :D

Vois pas le rapport,

Le genre de débat que nous avons ici, ne vaut pas plus que quelques clous. Tes clous comme les miens.

Tout à fait ! Mais faut choisir, tu peux pas prendre les atouts de C/C++ quand ca t'arrange (pas de VM toussa) et ceux de Python/Ruby quand ca t'arrange :) Ce mix ca s'appel les solutions intermédiaires de type .NET/Java, avec en plus des services non proposés par les extrêmités ;-)

Non, ça s'appelle des solutions hétérogènes C/C++/python/ruby.

Avoir aucun débordement de tampon possible, assurer qu'un soft ne puisse pas attaquer directement l'OS (et y attaquer d'éventuelle faille de sécu), bénéficier de la "légèreté" des thread sans sacrifier l'isolation qu'offre les processus mais en plus "lourd". Ca suffit non comme atouts ? Trouve moi des désavantages :)

Aucun débordement de tampon possible... oulala, tu as du faire rigoler des gars en sécu. Les OS courant ont déjà pas mal de difficultés avec de l'aide du hard et magie... tu balances que les VM sont toutes super plus sécure que les OS sur lesquelles elle tournent en utilisant les même mécanismes... ça c rigolo... :D En tout cas, ce que tu me décris est bien les fonctions d'un OS... un inconvénient, un énorme tas de code compliqué redondant vis à vis du code de l'OS: arithmétique simple: plus de code=plus d'emm*****. La VM sert à rien, tu as du hard, tu met linux et tu te fais pas ch*** avec le paquet de code de la VM.Linux est une super VM. Tu verras.

Encore t'as définition du "plus libre" et du "moins libre". Pourtant les licences sont souvent les mêmes... Et puis parrot n'offre pas tous les services qu'offre les autres plateformes.

Le libre dans logiciel libre ne signifie pas *que* des licences "libres", si tu n'as pas pigé ça... Pour parrot ce qui m'embête c'est qu'elle se bloatifie très vite à cause de la volonté de supporter tous les langages de la terre! Perso, il faut suivre parrot de prêt, il paraît que perl6 bombera avec elle.

Et donc ?

Et donc j'ai répondu à ta question.

On dirait que t'ose pas citer une plateforme :) Allez vas-y, propose moi une alternative :)

Bon allez... je vais récupérer ce que j'ai dit dans un précédent message pour te faire plaisir

sylware a dit:
L'ensemble des OS/Langages/bibliothèques libres.

Le problème dans ton discours c'est que tu nous ressorts à chaque fois une solution différente pour chaque aspect alors qu'on insiste ici sur le fait que la force de Java ou de Mono est la mise à disposition d'une plateforme "cohérente" et pas composée de bouts assemblés dans tous les sens et inmaintenables.

Tout à fait, linux est inmaintenable, python non plus, ruby non plus, KDE, gnutls; openssh; xorg, mozilla, gcc.

Fort bien, tu as erlang qui traite mieux le developpement distribué. Mais il tourne sur un "runtime". Il offre donc lui aussi des services de l'OS ? Alors tu préfères un OS ou un runtime? Et comment tu fais pour prendre le meilleur de Erlang et de python ? Tu bases ton architecture sur des composants qui communiquent avec un protocole et une infrastructure communes (bus). C'etait pas un peu l'idée de Corba au départ. Hélas même les devs de KDE et de Gnome lui ont tourné le dos en l'adaptant à leur sauce parce que les perf étaient dégradées en environnement "non" distribué.

Euh... tu te goures, ORBit à la réputation d'être rapide. KDE à dropper corba car ct inutilement complexe et lourd pour les tâches d'un desktop. Miguel De Icaza, le MS copycat de gnome, à eu la très mauvaise idée de copier le modèle de composant MS COM pour le mapper sur corba. Gnome le drop pour embrayer sur dbus aussi à cause de la complexité.

Alors maintenant tu as ta dipsosition des plateformes libres ou "quasiment" qui offrent des services prêts à l'emploi et permettent de rajouter des composants (JEE, Mono, XPCOM-Mozilla, UNO -OpenOffice, ...). Mais le choix se réduit encore lorsqu'il faut couvrir le réparti, le local, le mutili OS.

JEE Mono sont des technologies dont l'indépendance et très discutable... je ne me contente pas d'une licence libre quand je parle de logiciel libre. XPCOM-Mozilla est très simple comparé à ces derniers. Je ne sais pas pour UNO.

Tu as aussi la solution de récupérer toutes les technos du libre éparses et de les assembler par des ponts divers et variés. Quid de la cohérence, la montée en charge, la stabilité sur une architecture exotique ?
Le piège du soi-disant "oligopoles" se transforme en la quête du mouton à 5 pattes et la chasse à la compléxité superflue?

Pour ma part, je préfère mettre ensemble des composants simples qui font bien leur boulot (cf moto d'unix), et cela ne signifie pas du tout "complexité" que d'avoir tout regroupé dans une super plateforme qui tente de tout faire. As-tu regardé les spécifications de java, celle de .net... c'est horriblement complexe, même corba m'a semblé plus simple à côté. Le bilan est le suivant: tu vois des frameworks d'une complexité inouïe passés en force, alors que de l'autre côté par la pratique et à la force de la raison, comme tu l'as souligné avec corba, on les abandonne ces bloats complexes pour un ensemble de petits éléments plus simples.

Et quelle librairie graphique portable s'interface avec Erlang. Qt ? Est-ce adapté pour tirer bénéfice des possibilités du langages. Quand on voit les trésors d'ingéniosité déployés par l'auteur de PyQt pour étendre le mécanisme des signaux/slots et les rendre dynamiques, on comprend qu'un langage conditionne une architecture.

Erlang bourrine dans les télécoms paraît-il. Si tu veux mettre un interface graphique à une framework pensé pour les télecoms, libre à toi.

Et pour revenir sur les services du runtime qui s'apparentent à celui de l'OS. Comment assurer simplement la portabilité entre OS justement, si tu bases ton code sur des spécificités d'un OS. suggeères tu que la portabilité soitassurée par l'OS. Ce que tu reproches à M$ tu voudrais l'imposer. Les runtimes encapsulent justement ces services avec une API commune et lorsque les spécificités de l'OS permettent d'optimiser ces
services, elles sont prises en compte.
La section critique se base sur des mécanismes offerts par l'OS (sans quoi elle ne serait pas fiable) et pourtant c'est bien un service offert par le langage ou le runtime qui est de plus haut niveau que le sémaphore (je ne connais pas les détails de l'implémentation, aussi je peux me tromper mais c'est sur l'idée que j'insiste).

Bon je récapitule MA vision des choses:
Je vois des frameworks d'une complexité à la all-in-one(cf specs), dont l'indépendance est sujettes à caution, qui sont poussés complètement artificiellement sur le devant de la scène. Leurs langages en terme de difficulté est similaire au C/C++ donc rien de significativement novateur (spécial dédicasse pour qui celui qui se reconnaitra).. Par contre , en cado bonux tu as une VM à maintenir pour chaque combinaison OS+HARD qui finalement fait du JIT car trop lente (chercher l'erreur).
Je vois la montée des langages dit dynamiques (python, ruby ...). Beaucoup plus simples que leur homologues précédent avec un interpréteur loin de la complexité des VM précédentes car ne se vantant pas d'aller plus loin que la complexité déjà élevée des OS courants, et puis surtout c'est "libre", pas Sun ni MS...
On me parle de cohérence d'une plateforme, alors que les termes adéquats seraient homogène et hétérogènes. Mais l'opposé de cohérent ça fait péjoratif. Donc tout ce qui n'est pas "cohérent" est BIP! Donc tout ce qui est pas leur framework est BIP! En fait, ces frameworks sont plus homogènes (comme zope)... par contre cela n'empêche en rien un système hétérogène d'être parfaitement cohérent!
Ensuite, quand on regarde ce qui se passe: beaucoup de projets du libre recherche la simplification par modularisation (divide and conquiere) ou carrément abandonne les bloat complexes: xorg qui se modularise et qui sous peu sera le berceau de XCB, gnome qui drope finalement corba car trop complexe, mozilla qui passe à xulrunner. Et malgré ça, on apprend toujours pas, tu en as toujours pour pousser de nouveaux giga bloat complexes et donc refaire les mêmes erreurs...

Désolé mais t'es gonflant à sortir des affirmations gratuites sans la moindre argumentation ou exemple pour ettayer.

C'est vrai que toi par contre, c'est merveilleux. Ça va les chevilles?

Si bien entendu, mais il est limité à une séparation des adresses mémoires entre les processus. Cela peut être géré de manière beaucoup plus fine et intelligente au niveau d'une VM, sans d'ailleurs à avoir à se soucier de ce que fait tel ou tel OS (qui a dit application portable ?).

A quoi ça sert d'avoir une gestion plus fine à part avoir du code à priori plus complexe? Tu veux dire que le modèle d'abstraction des VMs est plus sophistiquée que celui des OS courant?

C'est pour ca que je te disais : montre moi le "super" service d'introspection. C'est vraiment limité, bien souvent c'est du "parsing" de source (yahoo), et à l'exécution t'as rien du tout, la génération de code dynamique tu peux également te toucher, enfin bref, c'est pas ce que j'appel un service d'introspection digne de ce nom.

Python/ruby et probablement d'autres offrent ce service d'introspection sur leur "objets", non? D'ailleurs j'avoue que le concept existe depuis longtemps dans les middleware objet. Je n'ai jamais eu l'occasion de développer du soft qui en avait besoin.

Ces langages peuvent tout de même être compilés, il existe par exemple IronPython, une implémentation de Python pour .NET/Mono. Le résultat : gains de perfs et accès à toutes les bibliothèques de la plateforme. C'est où les inconvénients ?

Pourquoi je bloaterais mes programmes en python? 5000 lignes de C (commentaires+lignes vides) l'interpréteur de CPython... combien pour les autres VMs? Je choisirai parrot comme VM alternative qui semble bien plus libre que les .net/Java and co. Mais bon, ce que je recherche avant tout c'est la simplicité et le dynamisme des langages comme python/ruby/perl and co, pas une VM. Je serai content avec l'interpréteur le plus léger possible pour chaque langage.

Si tu veux, mais tu veux démontrer quoi exactement ?

T'insiste sur le fait que les VMs sont plus proches du langage machine, à ce que j'ai vu, elles sonts plus proches des services d'un OS.

Mais c'est quoi la 3ème voix ? Elle est où la plateforme qui intègre tout ce qui est nécessaire pour faire des appli n-tiers avec serveur d'applications, clients lourds, pages web dynamiques, un modèle de composant et des perfs décentes ?

Cf messages précédents
.

Ben justement, c'est ce que fond tous ceux qui implémente des JVM, des serveursr d'applications J2EE et tout le tintouin.
Visiblement le libre est incapable de gérer une plateforme d'une telle taille de manière cohérente, alors il se contente de "singer" le proprio. C'est dommage, mais en attendant on n'a pas d'alternative, à moins de se "contenter" des technos hétéroclytes que tu cites, en ayant la moitié des services en moins, pleins d'incohérences, de difficultés d'intéractions, des problèmes de déploiement, des technos très différentes à assimilés pour un résultat... ben non y'en a pas.
(J'exagère, puisque Zope existe, mais comme le montre cette news, avec des limites).

Cf messages précédent.

Donc j'en remet une couche: chers amis du libre, attention aux technologies à l'indépendance douteuses. Choisissez vos composants logiciels les plus libres possibles: préférer les plateformes C/C++/python/ruby/erlang/php/perl/linux etc... etc... pour développer vos applications.

T'as déjà écrit une application répartie ? T'as déjà déployer une application sur plus d'une plateforme ?
Monsieur le client, c'est open-source, démerdez-vous pour recompiler, et tant pis pour l'application répartie !
T'as aucune idée de ce qu'apporte une plateforme de type Java/.NET, et ca se voit.

A mon tour :) ! Puisque tu es à plein temps sur les journaux et que j'ai un peu de temps on va s'amuser! Je vois que tu as vu que j'avais placer Erlang. Framework pour la mise au point d'applications distribuées. Pour dire vrai, la dernière fois qu'on a m'a proposer un poste dans la téléphonie mobile, ct pour gérer l'infrastructure de déploiement de programmes sur les JVM certifiées J2ME. Bin il avait des matrices de compatibilité dans tous les sens car la portabilité binaire ct du pipo.
Hum... en tout cas, ce qui ce voit même pour un non initié, c'est ton aggressivité.

Mais arrête d'affirmer n'importe quoi sans argumenter !
Explique moi comment tu peux offrir en C/C++ les services d'isolation mémoire offert par les VM ? Montre moi le super service d'introspection qu'offre C/C++ histoire de rigoler un coup !

Isolation mémoire? C'est pas un service de l'OS par hasard? Processus? Je sais que la VM est un OS au dessus de l'OS mais bon, pas la peine de le rappeller à chaque fois. Introspection? Je sais qu'ils travaillent dessus sur les gobjects de la glib et qu'ils s'en servent pour générer les bindings de python (ruby quelqu'un?). À part cela je n'ai jamais été confronté à ce jour à l'utilité de l'introspection.
C'est vrai que je réduis en parlant seulement de C/C++/python/ruby/perl/php etc etc... il faut que je mettre aussi l'OS dedans pour essayer d'avoir un tout plus cohérent fonctionnellement. Donc linux dans mon cas.

C'est pas en faisant l'autiste qui se répète avec force "c'est pas significatif" que ca va rendre ton affirmation plus vraie.

Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?

Oué c'est clair, d'ailleur c'est pour ca que tous les langages modernes de l'open-source (Ruby, Python & co) utilise une VM pour s'abstraire du matos. C'est pas parcque t'as les sources que ton appli va forcement tourner sur toutes les plateformes quand elle est écrite dans un langage bas-niveau. T'as tous les problème d'alignement mémoire, les types de base (entier, etc.) qui n'ont pas la même représentation sur toutes les machines, enfin bref, un vrai bordel. Et t'as intérêt d'avoir des "bons" programmeurs qui savent éviter tous ces problèmes.
Ah oui, et tout le monde n'est pas sur slackware, y'a même des linuxiens qui utilisent des distributions basés sur un système de package binaire, et rien de plus "pète couille" que d'avoir des repositories non compatibles pour la simple et bonne raison que tout le monde recompile dans son coin les mêmes appli. (Exemple typique de problème de déploiement).

Hum, la VM dans les langages comme python, ruby and co, sont probablement adapté au dynamisme de ces langages. Je pense même qu'il est plus préférable d'utiliser le terme "d'interpréteur" pour ces langages.

Non c'est tout à fait comparable. Une VM offre un jeu d'instruction qui s'apparente à l'assembleur. Il n'y a effectivement pas "seulement" ca, mais il y a "aussi" ca. Y'a effectivement de nombreux services annexes qui peuvent pour certains s'apparenter à des fonctionnalités d'un OS.

J'ai considéré le byte code dans ça globalité. Pour moi cela reste plus proche des services d'un OS que d'un jeu d'instructions en assembleur.

Et une affirmation, et une !
C'est quoi cette plateforme alors ?
Nan parcque ca intéresserait des millions de développeurs/entreprises

L'ensemble des OS/Langages/bibliothèques libres. Hum... là tu as raison... il ne faut pas diminuer les efforts pour mettre au parfum un maximum de monde et d'entreprises sur la "troisième voix".

C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
T'as en partie compris le problème du libre : il n'y a aucune plateforme cohérente qui propose l'ensemble des services que propose Java/.NET. Zope est une des rares solutions à proposer un serveur d'application. Mais Zope est loin de proposer tout ce que fourni J2EE par exemple. Et visiblement le choix d'un langage interprété dynamique montre ces limites. C'est même pas imaginable en C/C++, c'est bien qu'il manque une brique indispensable entre les 2. Devines laquelle.

Et après c'est moi qui affirme sans argumenter... Ce qui va faire pencher la balance c'est la sensibilité de chacun. Le tout est de bien avoir été exposé à un maximum d'arguments afin de faire un choix qui convient le mieux.
Plateforme cohérente? Ça veut dire que les autres sont incohérentes :D! Tu veux dire que le prix de l'indépendance vis à vis de l'appropriation de l'informatique par un oligopole d'entreprises est avoir de nombreux composants intéropérables pour former une informatique cohérente? Si ça n'avait pas été le cas, très vite tout le logiciel libre aurait été noyauté par le petit nombre d'entreprises que l'on connait bien.
Perso, je conseille vivement à ceux qui nous lisent de faire évoluer les solutions basées sur les linux/C/C++/python/ruby/perl/php.... Dans la majorité des cas, je pense qu'elles vont donneront pleinement satisfaction, et si il vous manque une brique, n'hésitez pas à monter des projets libres pour que le développement soit collaboratif.

Après le Novell Blog System voici le Nuxeo Blog Sytem!

Perso, il faut que je vois si je continue à perdre mon temps ou non...
Mais de temps en temps ç'est bon de participer car cela me permet d'augmenter et d'améliorer mon arsenal argumentaire.
:)

Tu fais exprès ou quoi ? La portabilité binaire c'est pas significatif ? Tous les services que j'ai décris c'est pas significatif ? La sécurité c'est pas significatif ?

Je passe outre une fois de plus sur le début de tes propos. La portabilité binaire? Sur des logiciels libres donc open source? Allons un peu de sérieux. A quoi sert la portabilité binaire avec des logiciels open source? Allez... on va dire quasiment à rien.
Tous les services que tu décris et la "sécurité" (très à la mode) ne sont en rien l'exclusivité de ces VMs. C/C++/ruby/python/perl/php offrent la même gamme de services, d'ailleurs souvent ses services sont des librairies en commun à toutes ces plateformes et langages.

T'utilises les adjectifs qui t'intéresse sans rien démontrer, sans un cas c'est "pas significatif", dans l'autre c'est "immense". Alors montre moi les "immenses" désaventages d'une VM pour des plateformes de type Java/.NET.

Quand un composant logiciel qui fait des milliers de lignes de codes, et qu'il ne m'apporte rien de significatif et bien pour moi c'est un immense désaventage.
En fait, il faut plutôt retourner la question: qu'est-ce que m'apporte l'utilisation d'une VM (dont l'indépendance est très discutable en plus) dans le monde libre/open source pour des langages non dynamiques?

Euh, la portabilité binaire en code natif je demande à voir... A moins de t'amuser à faire des universalbinaries comme Apple, qui multiplie par 2 la taille de ton code et qui te demande du travail en amont, désolé, je vois pas.

Bof la portabilité binaire dans le monde du libre/open source. Pas la peine de revenir dessus.

Bravo ! Tu viens de trouver un autre avantage largement significatif des VM : l'indépendance vis-à-vis de l'OS !

Je faisais remarquer que tu avais tord en comparant le byte code des VMs (que j'ai eu l'occasion de survoler) au jeu d'instructions des langages machines, mais qu'il fallait plutôt le comparer aux fonctions qu'offrent un OS/bibliothèques de base. Quand à l'indépendance de l'OS, une fois de plus, cela est loin d'être l'exclusivité de ces VMs.

Oué, y'a le vrai libre et le faux libre. C'est vraiment n'importe quoi ton raisonnement. Tu cherches des arguments techniques complètement bidons pour justifier au fond une préférence éthique envers les LL.

Pfff... ce que tu peux être aggressif. Là j'avoue que pour le libre, j'ai aussi une préférence éthique: comme le dit Linus, on est sur un modèle de travail collaboratif et on a prouvé qu'on pouvait faire du travail aussi bon voir meilleur que sur le modèle de la compétition acharnée. Bon, il faut relativisé dans le sens où ça n'est pas vrai pour tous les domaines. Ça serait trop beau! J'en suis tellement convaincu, qu'il est pour moi immorale de fournir mes compétences à tout autre type de logiciels. Attention tout n'est pas blanc ou noir et ma moralité n'est pas sans faille. C'est une question de feeling... en général je procède par élimination: si je ne peux pas utiliser un soft GPL/LGPL je regarde du côté des softs BSD et si toujours je n'y arrive pas je passe au propriétaire si il existe. Si vraiment je juge que la fonction du soft est importante pour mon travail et que l'existant ne me convient pas, je n'hésiterai pas une seconde à monter un projet GPL/LGPL.

Tu ferais bien de te poser une question : pourquoi n'y a-t-il pas d'équivalent avec une techno libre (une vraie comme tu dis) à J2EE ? Parcque les langages interprétés de type Python&Co n'ont pas été conçu pour ca, et les langages natifs de type C/C++ le sont encore moins.

Ça n'est pas vrai. L'ensemble des logiciels libres couvre largement ce que sait faire J2EE/.NET aussi bien ou mieux et sans les soucis d'indépendance de ces technologies vis-à-vis de leur entreprise mère respective.

Evidemment qu'ils ne sont pas révolutionnaire, mais ce sont des évolutions non négligeable.

reBof... évolution... non, plutôt pétard mouillé technique mais bombe H marketing. Les tirages de couverture entre Sun&Co et MS me gonfle. Heureusement, il y a une troisième voix.
Personnellement, je ne perdrais pas mon temps avec ces technologies. Je suis très bien avec la qualité de l'offre libre/open source en C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
cheerokee etc etc... je serais pas fute-fute de me lier à ces technos si discutables alors que j'ai une plétor technos sans ce soucis et parfaitement opérationnelles à porté d'un click sur le net.

Hum... bien argumenté.
Ça fait plaisir à voir.

Effectivement, quand on prend du recul et qu'on laisse tomber toute mauvaise foi: linux+biblios libres est de très loin le framework le plus portable et performant que je connaisse.
D'où l'inutilité de l'existence de la VM pour les langages non dynamiques.
Les langages dynamiques (python/ruby/perl etc...) tournent sur différentes VMs. Cela dit, il est maladroit de faire tourner ces langages sur des VMs qui ont été pensées pour des langages non-dynamiques. On obtiendrait à priori de bien meilleurs résultats à les faire tourner sur des VMs qui ont été pensées à la base pour leur dynamisme.

Pour moi ils tirent justement des langages compilés les atouts : à savoir la typage statique (souvent propre aux langages compilés même si pas toujours vrai), et justement la possibilité de compiler le code de la VM en code natif, donc avec des performances décentes.

Effectivement, ce que tu avances c'est que ce genre de langage n'apporte rien de significatif par rapport aux langages compilés nativement. Par contre ils ont l'immense désavantage de dépendre d'une VM lourde et complexe (souvent proprio d'ailleurs).

Parcque justement le jeu d'instruction d'une VM est plus simple (et non plus complexe) car de plus haut niveau qu'un jeu d'instruction assembleur. Le compilateur JIT n'est pas un aveu de lenteur puisqu'il fait partie intégrante de la solution. Ce qui compte c'est le résultat : c'est du code machine qui s'exécute, on ne sacrifie pas la portabilité, pas trop les perfs, on garde du code de haut niveau, avec la possibilité d'y adjoindre de nombreux services qui participent à la qualité du code : sécurité, gestion mémoire, introspection, etc.

De ce que j'ai lu des jeux d'instructions des VMs est beaucoup plus proche des services offerts par un OS/bibliothèques de base que d'un jeu d'instructions assembleurs.
C'est pour cela que je dis qu'une VM proprio ne vaut guère plus qu'un OS proprio.
Aujourd'hui avec l'offre des bibliothèques du libre on tourne sur plus de plateformes que les VMs SANS dépendre d'une VM. De plus la portabilité n'est pas l'exclusivité des VMs...

Au final, ces langages n'apportent rien de significatif par rapport à ce qu'offre le vrai libre: C/C++/python/ruby/perl/php etc. Je dis le vrai libre car ces langages ressemblent plus à des putch marketeux sur l'informatique. Ils ne sont pas révolutionnaires, même plutôt maladroits pour les raisons que j'ai évoquées précédement.

Peut être que le jour où tu participeras au développement d'une grosse solution logicielle de plusieurs dizaines de milliers de lignes de code, tu apprécieras tout les services de ces plateformes, qui n'ont d'autre objectif que de te rendre plus productifs et donc globalement plus agréable à utiliser.

Outres les attaques personnelles à coup de "j'ai la plus grosse", j'apprécie énormément tous les services que m'offrent les bibliothèques du libre d'une portabilité sans éguales qui sont un véritable plaisir à utiliser et qui me rendent plus productifs sans avoir à dépendre de technologies lourdes ,complexes, maladroites et au final inutiles dont l'indépendance est très discutable.

Il faut sortir la tête du sable: Python est un des langages les plus facile à maîtriser.
De plus, les langages (je devrais dire plateformes) reposant sur une compilation de code statique pour ensuite tourner sur des VMs, et bien c'est pas très futé (j'aurais tendance à être beaucoup plus cassant...).
Ces derniers cumulent les désavantages des langages compilés nativement, c'est à dire bien plus complexes à maîtriser que les langages dynamiques comme python (et les autres!), ajoutés des désavantages des langages dynamiques, comme tourner sur une VM (parfois prioprio... donc encore pire... ça ne vaut gère mieux qu'un OS proprio... mais je me répète). Pour enfoncé le clou, ils ont inventé la compilation JIT, qui est un aveu même de la lenteur d'exécution de ces langages: A quoi bon avoir la complexité et la lourdeur d'une VM (allez proprio pendant qu'on y est) avec une compilation JIT, si c'est pour tourner en natif?? C'est particulièrement c... ahem... disons plutôt: "It's not a limitation... it's a feature!"

La technique est simple: tu prends une boîte qui bosse pas avec tes technos et qui a une certaine crédibilité dans un milieu où il y a des dèvs/geeks/entousiates qui roxent. Tu passes "un partenariat" ou tu mets un gros paquet de pognon sur la table avec le deal suivant: "vous laissez tomber vos technos et passer aux nôtres en hurlant que les nôtres sont plusse meilleures". Bin voilà... le tour est joué! Personnellement ça m'éc½ure...

Alors là... Je ne sais pas combien de journaux on a eu droit sur le sujet. Bluffant...

Est-ce que ce nouveau CPS tournera sur une VM libre??

Parce qu'il faut le souligner, une VM proprio ou un OS proprio c'est la même chose.

Je tiens à rappeler qu'il est possible de faire la même chose en beaucoup plus libre avec python/ruby/perl/php/C/C++ etc etc...
Je vous encourage à être le plus libre possible dans vos choix de plateformes technologiques.

JBOSS tourne sur une VM libre?
Car un OS proprio et une VM proprio, c'est la même chose.

Arf! Le coup de l'amalgame! Va falloir que tu laisses tomber le marketing... parce que là...

Dans le contexte qui nous intéresse ici, je vais faire remarquer que le programme java ne tourne pas sur une VM libre et que ça ne vaut gère mieux que d'être "locké" sur OS propriétaire (entre autre). Et qu'il vaut mieux utiliser des technologies comme python/ruby/perl/php/lua/haskell.... qui font pareil mais en vraiment libre.

Bin... je suis joueur occasionnel sur Quake4 et j'ai exactement le même pb. Je n'ai jamais été capable de faire descendre la console.

Bin alors?!
Il faut le dire, bon sang!
Le crier haut et fort: "Et ce code libéré tourne très bien sur une VM libre (sur gcj en l'occurence)".
Bon bien sûr il faut que le code soit exploitable sur la VM libre et pas se contenter de le faire tourner sans planter.... c'est pas pareil...

Les dèvs de sylpheed claws sont en train de faire la même erreur qu'Evolution...
En effet, ils sont en train de mettre dans leur application tout un système de groupware (email, calendrier, contact, crypto...).
Evolution est limite trop complexe et un sacré balourd.
Le moto d'unix est de faire des apps spécialisées qui font bien leur boulot.
Il faudrait que le desktop offre un framework pour le groupware. Normalement, c'est la tâche de freedesktop de fournir cela.
Par exemple, une app pour gérer les contacts, une autre app pour gérer les calendriers, encore une autre pour gérer les émails...
L'app pour gérer les émails ne ferait qu'appeller les services du desktop pour les contacts et la crypto par exemple. On pourra lancer l'app de gestion des contacts et/ou l'app de gestion de la crypto à partir de l'app de gestion des émails.
Le tout est de sortir la logique de chaque type d'app et d'en faire un service provider.
Lors du design de ces services desktop (probablement basés sur DBUS), il ne faudra pas tomber dans le travers de la super complexité avec la mauvaise excuse de la flexibilité... enfin bon, il faut déjà que quelqu'un en ait le courage de se coltiner le boulot. Surtout qu'il y aura pas mal de ratés avant d'avoir réussi à décrire tous ses services de manière élégante.

Arg. Oui. J'ai récupéré une mauvaise information. Honte sur moi. Et ouch, ça veut dire que mes illusions sont mortes pour Novell.
Cela dit, le roi de l'intéropérabilité chez Apple... hum... je me demande ce que ça va donner sur les itunes/ipod.

Du code libéré, c'est toujours ça. Rien à dire... j'suis complètement d'accord.
Mais il est bon de tempéré. Ce journal est chargé de positivisme... et en oublie comme par hasard ce petit point de détails-->ça ne tourne pas sur une VM libre.
Un journal équilibré sur ce site dans le cas d'une libération de code java devrait systématiquement ajouter la mention: "hélas, ce code pourtant libéré en GPL/LGPL ne tourne pas sur une VM libre... sniff :'( "
Mais bon... ça fait tout de suite moins marketing car rappelant la triste vérité.