Logiciel : Nuxeo CPS tournera sous Java
Posté par Stefane Fermigier (page perso, ). Modéré le 28 septembre 2006.
Le logiciel a été au passage renommé Nuxeo 5, et devrait sortir au novembre d’après la feuille de route du projet. Il sert à réaliser des applications à la fois en environnement serveur (Java EE) et en environnement client riche (RCP).
Il repose sur
- un module qui fournit un système de composants extensibles et faciles à déployer et baptisé Nuxeo Runtime. Ce module peut d’ailleurs être utilisé dans tout type d’application Java. La version 1.0 a été annoncée cette semaine,
- un “coeur de gestion documentaire”, Nuxeo Core qui fournit les fonctions de base de la gestion documentaire, et qui peut être embarqué aussi bien dans des applications serveurs que clientes. La version 1.0 sortira en octobre
Nuxeo 5 utilisera la licence LGPL.
![[en]](../images/en.png)
Nuxeo 5 (1190 hits)![[fr]](../images/fr.png)
La FAQ sur le passage à Java (581 hits)-
Interview de l'équipe technique sur InfoQ (173 hits)
-
Le module Nuxeo Runtime (114 hits)
-
Nuxeo CPS (187 hits)
> Lire la dépêche (175 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #759789.
Former des développeurs Python/Zope compétents
nos clients et nos partenaires nous ont rapporté avoir d'importantes difficultés à trouver ou former des développeurs Python/Zope compétents.
On entend souvent ce discours comme quoi il manquerait de programmeurs python, avec ici une couche supplémentaire disant qu'ils sont difficiles à former. Je trouve ça vraiment très bizarre car python est vraiment un des langages les plus facile a apprendre, et spécialement au sein de Nuxeo il doit y avoir largement de quoi former les nouveaux arrivants (en interne ou pour des clients).
Alors que la tendance actuelle est de plus en plus orienté langages de script, que ce soit chez MS avec ironpython ou chez Sun avec jython et jruby, est-ce que jython a été envisagé pour tirer partie du meilleur des deux mondes ?
[^]Re: Former des développeurs Python/Zope compétents
Ce n'est pas si simple.
N'oublie pas que tous les développeurs ne sont pas des adeptes du libre, loin loin de là. Beaucoup ne souhaite pas s'investir dans une technologie dont il n'ont jamais entendu parler.
Aujourd'hui il reste plus facile de trouver un développeur java qu'un développeur python.
Et même si on en trouve un il reste la peur de se retrouver seul utilisateur d'une technologie que tout le monde a fini par abandonner (qui se souvient de Pacbase...)
[^]Re: Former des développeurs Python/Zope compétents
Moi ! J'ai été formé à Pacbase il y a un an et demi et depuis je n'ai pas arrêté de coder avec (projet mis en prod il y a quelques jours).
Pacbase est toujours trés utilisé dans les banques et les assurances françaises (qui refusent que IBM en cesse le support d'ailleurs). La seule chose qui a changé c'est qu'on ne fait plus d'écrans 3270 mais qu'à la place on a un pont permettant d'appeler le site central depuis une appli J2EE.
J2EE que par ailleurs je trouve immonde, enfin surtout les jsp. Je n'aime pas du tout cette façon de faire de mélanger dans une seule page de code plusieurs langages (html et java en l'occurrence, voire javascript en plus bien souvent - mais c'est pareil avec php d'ailleurs).
[^]Re: Former des développeurs Python/Zope compétents
Le problème dont tu parles à propos des JSP (mélange de genres) est connu depuis de nombreuses années et de très nombreux frameworks, API, et standards ont pour objectif de gérer ce problème en minimisant voire annulant la présence de code Java et JavaScript dans les JSP.
Seul un vraiment mauvais programmeur te fera un mix ingérable de HTML et Java dans une JSP.
[^]Re: Former des développeurs Python/Zope compétents
C'est vrai, et à chaque fois il faut se retaper l'étude du framework en question, différent d'un projet à un autre, avant de pouvoir pondre une page.
De ce coté là je préfère nettement l'approche des templates de turbogears (kid) ou rubyonrails: tu connais le langage (python ou ruby) => tu peux écrire les templates dans ce langage
[^]Re: Former des développeurs Python/Zope compétents
Excuse moi mais c'est stupide ce que tu dis ...
Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).
Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.
Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage
Vache qui rit, à moitié dans son lit
[^]Re: Former des développeurs Python/Zope compétents
Excuse moi mais c'est stupide ce que tu dis ...
Merci, ça fait toujours plaisir
Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).
Je ne dis pas qu'il faut mettre du java dans ses JSP, d'ailleurs je ne le fais pas.
C'est justement les taglib que je n'aime pas: cette manie de faire de la programmation en XML, désolé mais ça me saoule. D'ailleurs rien à vois mais ça m'y fait penser: ant est pas mal non plus à ce niveau là.
Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.
Ben des fois tu change de projet, de client ou tu bosses sur plusieurs en même temps.
Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage
Ce que j'aime pas avec les jsp, c'est qu'il te faut connaitre tout un tas de taglib, dont les mots clé sont evidemment différent de ceux de java, et la sémantique pas toujours très claire. Et accessoirement il faut aussi connaitre EL.
Regarde l'exemple fourni sur le site de KID :
http://www.kid-templating.org/trac/wiki/KidExamples
C'est quoi dans les attributs? ben c'est du python: j'ai rien de plus à savoir. pas de langage pour les expression, ou autre taglib.
[^]Re: Former des développeurs Python/Zope compétents
J'ai fais l'effort d'apprendre python, car ce langage m'intéressait, notamment pour mes projets universitaire, il y a 5-6 ans maintenant.
Mais je n'ai jamais pu travaillé en python en entretreprise, car tout le monde ne jure que par Java, et je trouve que c'est dommage.
Donc je fait du java, comme tout le monde, et souvent je peste...
[^]Re: Former des développeurs Python/Zope compétents
Just do java and be right: it's more than time to come out and be proud !
We all have to concentrate and favour the industrie's choices in order to build the magnificent world of tommorrow !
Let me also urge everybody to comment in english, because this is the only free language.
Of course french has qualities, and is also technically free, but not economically: so few people can anderstand anything but english that we might restrict ourselves to a very little shortlist of potential commenters if we don't switch asap.
[^]Re: Former des développeurs Python/Zope compétents
Pareil, je ferais volontier du Python mais je ne vois rien sur Lyon autour de ça.
[^]Re: Former des développeurs Python/Zope compétents
Y a quelques mois il y avait un poste très intéressant sur Lyon chez Fluendo... Et apparement ils avaient beaucoup de mal a trouver des compétences en Python. C'est un cercle vicieux, pas de compétences donc pas d'investissement etc.
Le mieux c'est de sortir de ce vislard de cercle et se mettre à son compte, on peut faire du Python toute la journée :-).
[^]Re: Former des développeurs Python/Zope compétents
Ouip à l'époque j'ai postulé mais mon profil n'était pas celui recherché (trop d'études, trop d'expérience). J'étais prêt à négocier mais il ne m'en ont pas laissé le temps. Après un échange par mail il ne m'ont plus jamais répondu.
[^]Re: Former des développeurs Python/Zope compétents
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...
[^]Re: Former des développeurs Python/Zope compétents
Moué alors on peut très bien prendre tous tes arguments et les tourner dans l'autre sens :
"Ces derniers cumulent les désavantages des langages compilés nativement,"
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.
"joutés des désavantages des langages dynamiques, comme tourner sur une VM "
C'est encore un avantage : abstraction de la plateforme matérielle, ce qui est le but premier, sans pour autant sacrifier les perfomances (le problème des perfs vient plutôt de la présence services ajoutés : gestion mémoire, sécurité, isolation, etc.).
"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"
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.
"It's not a limitation... it's a feature!"
Exactement, elles ont été conçu pour ca, et non l'inverse : le code machine n'offre pas la possibilité d'adjoindre tous les services que j'ai cité : il faut proposer un modèle plus "restreind" et de plus haut niveau : une machine virtuelle.
Bin voilà... le tour est joué! Personnellement ça m'éc½ure...
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.
MonoFrance
[^]Re: Former des développeurs Python/Zope compétents
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).
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.
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.
[^]Re: Former des développeurs Python/Zope compétents
Effectivement, ce que tu avances c'est que ce genre de langage n'apporte rien de significatif par rapport aux langages compilés nativement.
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 ?
Par contre ils ont l'immense désavantage de dépendre d'une VM lourde et complexe
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.
C'est pour cela que je dis qu'une VM proprio ne vaut guère plus qu'un OS proprio.
On s'en tape, on est sur LinuxFR, et on parle de logiciels libres, alors permet moi de ne considérer que les VM libres. D'ailleur au même titre qu'il y a des VM proprio il y a des compilos pour des langages "compilés en natif" qui sont tout aussi proprio. Je vois vraiment pas où tu veux en venir.
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.
Bravo ! Tu viens de trouver un autre avantage largement significatif des VM : l'indépendance vis-à-vis de l'OS !
De plus la portabilité n'est pas l'exclusivité des VMs...
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.
Au final, ces langages n'apportent rien de significatif par rapport à ce qu'offre le vrai libre: C/C++/python/ruby/perl/php etc.
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.
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.
Ils ne sont pas révolutionnaires, même plutôt maladroits pour les raisons que j'ai évoquées précédement.
Evidemment qu'ils ne sont pas révolutionnaire, mais ce sont des évolutions non négligeable.
MonoFrance
[+] [^]Re: Former des développeurs Python/Zope compétents
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. 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?
Bof la portabilité binaire dans le monde du libre/open source. Pas la peine de revenir dessus.
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.
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.
Ç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.
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.
[^]Re: Former des développeurs Python/Zope compétents
Allons un peu de sérieux. A quoi sert la portabilité binaire avec des logiciels open source? Allez... on va dire quasiment à rien.
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.
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.
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 !
et qu'il ne m'apporte rien de significatif et bien pour moi c'est un immense désaventage.
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.
Bof la portabilité binaire dans le monde du libre/open source.
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).
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.
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.
Quand à l'indépendance de l'OS, une fois de plus, cela est loin d'être l'exclusivité de ces VMs.
Euh, par définition, pour être indépendant de l'OS/machine, il faut créer une couche d'abstraction... et c'est la définition même d'une VM : "machine virtuelle". Mais vas-y, plutôt que d'affirmer encore une fois de plus quelque chose, montre moi.
Là j'avoue que pour le libre, j'ai aussi une préférence éthique
Ben on est au moins d'accord sur un point.
i. 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.
Et une affirmation, et une !
C'est quoi cette plateforme alors ?
Nan parcque ca intéresserait des millions de développeurs/entreprises.
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.
MonoFrance
[^]Re: Former des développeurs Python/Zope compétents
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
Huh ? Slackware est basée sur un système de package binaire. Tu confonds avec Gentoo je pense.
[^]Re: Former des développeurs Python/Zope compétents
Euh oué au temps pour moi, désolé.
MonoFrance
[^]Re: Former des développeurs Python/Zope compétents
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é.
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.
Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?
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.
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.
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".
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.
[^]Re: Former des développeurs Python/Zope compétents
Bin il avait des matrices de compatibilité dans tous les sens car la portabilité binaire ct du pipo.
Oué, c'est J2ME, chacun y va se son implémentation et de sa sous partie des API qu'il a envie de définir. Restons côté J2SE/J2EE ok ? :)
Hum... en tout cas, ce qui ce voit même pour un non initié, c'est ton aggressivité.
Désolé mais t'es gonflant à sortir des affirmations gratuites sans la moindre argumentation ou exemple pour ettayer.
Isolation mémoire? C'est pas un service de l'OS par hasard?
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'ailleur à avoir à se soucier de ce que fait tel ou tel OS (qui a dit application portable ?).
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?).
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.
Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?
Non, mais au moins après avoir dis ca tu arrêtes enfin de répéter "non significatif" sans argumenté :) But atteint ;)
Je pense même qu'il est plus préférable d'utiliser le terme "d'interpréteur" pour ces langages.
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 ?
Pour moi cela reste plus proche des services d'un OS que d'un jeu d'instructions en assembleur.
Si tu veux, mais tu veux démontrer quoi exactement ?
il ne faut pas diminuer les efforts pour mettre au parfum un maximum de monde et d'entreprises sur la "troisième voix".
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 ?
t si il vous manque une brique, n'hésitez pas à monter des projets libres pour que le développement soit collaboratif.
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).
MonoFrance
[+] [^]Re: Former des développeurs Python/Zope compétents
C'est vrai que toi par contre, c'est merveilleux. Ça va les chevilles?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?
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.
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.
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.
Cf messages précédents
.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.
[^]Re: Former des développeurs Python/Zope compétents
C'est vrai que toi par contre, c'est merveilleux. Ça va les chevilles?
Vois pas le rapport, mais c'est vrai que j'ai essayé de te pondre quelques exemples.
- "oué c'est pas significatif"
- "Exemple1, Exemple2"
- "oué c'est pas significatif"
- "..."
A quoi ça sert d'avoir une gestion plus fine à part avoir du code à priori plus complexe?
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 :)
Python/ruby et probablement d'autres offrent ce service d'introspection sur leur "objets", non?
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 ;-)
combien pour les autres VMs?
Et ? C'est quoi le problème du nombre de lignes ? Linux il fait combien de lignes ? Gnome ? KDE ? c'est des gros bloats ! Je continue à utiliser ce bon vieux DOS tiens, au moins il tient sur ma disquette 3"1/4. C'est très maigre comme inconvénient par rapport à tous les avantages que ca apporte.
Je choisirai parrot comme VM alternative qui semble bien plus libre que les .net/Java and co.
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.
Je serai content avec l'interpréteur le plus léger possible pour chaque langage.
Oué pour faire du script ou des petites appli. Dès que t'as besoin de perfs ou de grosses applis, faut passer à quelque chose de plus sérieux. Un GC efficace, ca se code pas en 50 lignes de codes par exemple. Un compilateur JIT qui boost les perfs c'est pas 30 lignes. Après faut savoir ce qu'on veut, mais faut comparer ce qui est comparable.
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.
Et donc ?
Cf messages précédents
On dirait que t'ose pas citer une plateforme :) Allez vas-y, propose moi une alternative :)
MonoFrance
[+] [^]Re: Former des développeurs Python/Zope compétents
Le genre de débat que nous avons ici, ne vaut pas plus que quelques clous. Tes clous comme les miens.Non, ça s'appelle des solutions hétérogènes C/C++/python/ruby.
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.
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 j'ai répondu à ta question.
Bon allez... je vais récupérer ce que j'ai dit dans un précédent message pour te faire plaisir
[^]Re: Former des développeurs Python/Zope compétents
Non, ça s'appelle des solutions hétérogènes C/C++/python/ruby.
? 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 :)
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
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.
En tout cas, ce que tu me décris est bien les fonctions d'un OS...
Ca n'en fait pas pour autant un inconvénient.
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*****.
? 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.
Le libre dans logiciel libre ne signifie pas *que* des licences "libres", si tu n'as pas pigé ça...
Je préfères effectivement être libre d'utiliser l'implémentation que je veux d'une techno, en sachant que j'ai la liberté de changer si l'uune d'entre elle me pose problème, plutôt que de dépendre d'une seule implémentation (genre Ruby ou Python) où rien n'est standardisé, et où tout bouge sans cesse. Suis le processus de normalisation d'une norme Java, tu comprendras.
Et donc j'ai répondu à ta question.
Génial :)
L'ensemble des OS/Langages/bibliothèques libres.
...
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".
MonoFrance
[+] [^]Re: Former des développeurs Python/Zope compétents
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.C'est écrit en quoi une VM? Tu peux me le rappeler?
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:
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
[^]Re: Former des développeurs Python/Zope compétents
je te parlais de combiner C/C++python/ruby pour faire des applications hétérogènes.
Moi je voulais justement te montrer qu'il y a des plateformes qui sont homogènes, et qui prennent le meilleur de chaque 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.
RE:la portabilité binaire avec des soft open source portables... bof.
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.
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.
, tu ne peux pas d'abstraire du modèle et ordonnancement de threading des OS
Ben pourtant les VM y arrive...
Et puis le coût dont tu parles, si tu le considère pas trop élevé tant mieux pour toi, tu es riches
Euh, je te parle du coût dont tu parlais : y'a besoin de plus de 5000 lignes de code pour avoir des services efficaces et performants.
ui sont vraiment plus simples vraiment dynamiques et ont un interpréteur poids plume comparé aux VM de tes framework
Et alors ? Quand tu veux des perfs et des services éprouvées et testés tu fais comment ? Tu crois que Zope est "léger" et fait 5000 lignes de code ?
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.
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
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.
Ce que tu as du mal à comprendre, c'est que Java/.NET ne sont pas de simple "buzz" marketing, c'est avant tout une réponse à un besoin client. Et y'a de la demande. Je trouverai dommage que le libre laisse se créneau, heuresement y'a des gens qui penses pas comme toi et qui travaille à apporter ces technos dans le libre, dont le projet Apache (et ses nombreux framework Java), la FSF par l'interpédiaire de ses projets GNU (ClassPath, DotGNU, etc.), Novell, Red Hat, enfin tout ceux qui ont envie de faire progresser les LL plutôt que de le laisser à la traîne pour des raisons aussi débile que préférer une bouse interprétée qui va à 2 à l'heure mais qui fait "que" 5000 lignes de code !
MonoFrance
[+] [^]Re: Former des développeurs Python/Zope compétents
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.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: 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: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.
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
Oh quelle est belle! Voir para précédent.
Zope est une VM? Jt persuadé d'avoir parlé de l'interpréteur de python.
Et le J2ME "éprouvé et testé"TM fut inventé....
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.
[^]Re: Former des développeurs Python/Zope compétents
Tu devrais quitter le monde unix, car tu n'as pas très bien compris sa philosophie...
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...
en prônant exactement le contraire sur un site consacré à un des unix les plus populaires!
Je suis sûr un site consacré à GNU Linux, et GNU is NOT Unix ! :-p
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
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 !
re:Erlang?
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.
Le gestion de la mémoire(la vraie), tu crois que c'est pas dépendant de l'OS tout ça...
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.
Zope est une VM? Jt persuadé d'avoir parlé de l'interpréteur de python.
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.
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.
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.
Inutile de s'encombrer d'une VM additionnelle
C'est pour ca que tu me dis juste après de choisir parmi Python ou Ruby. Bordel soit cohérent. Soit tu dénigre les VM et t'arrête de me parler de ces solutions et on en revient à C/C++, soit tu reconnais qu'elles peuvent être utilent et on continue la discussion.
MonoFrance
[+] [^]Re: Former des développeurs Python/Zope compétents
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 pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
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.
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).
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.
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.
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!
[^]Re: Former des développeurs Python/Zope compétents
KDE et GNOME sont des assemblages cohérents de libs
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 !
. 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.
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.
Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
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 ;)
Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise.
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 ;-)
Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux.
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é).
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.
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 :-)
(tant pis pour eux, ils n'auront pas le meilleur de ce monde).
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 ...
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é.
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.
j'aurais tendance à virer la VM (beaucoup de code complexe),
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 ;)
Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles.
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...
. Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance
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.
C'est passionnant!
Oué bah j'espère que t'as la chance de ne pas faire la maintenance :)
MonoFrance
[+] [^]Re: Former des développeurs Python/Zope compétents
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.
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.
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
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.
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.
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.
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...
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.
"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.
...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.
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.
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.
[^]Re: Former des développeurs Python/Zope compétents
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...
On est d'accord, donc .NET et Java n'ont pas une lacune de ce côté là. Merci d'avoir confirmé.
Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java?
Ben, le JCP, organisme dédié avec des tarlouz comme Sun et IBM. Dans tous les cas il y a un effort de normalisation pour garantir l'interopérabilité. Et ca c'est le principal. On ne peut en dire autant de plateforme style Ruby, Python ou Php.
J'écoutais un discours de RMS qui rappellait qu'a la base, les logiciels étaient libres.
Rattrapes toi comme tu veux, Unix n'était pas libre à ses débuts. Heuresement RMS est arrivé.
Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr!
... T'es bête ou quoi ? Oui, si je me contente de développer une appli sur un OS, c'est évident que si y'a un trou dans l'OS j'y suis pour rien. Je suis responsable des trous dans mon appli uniquement. Alors moi je prégères contrôler au niveau de mon appli ce que je peux contrôler, et utiliser les services de sécurité de la VM (et l'indépendance vis-à-vis de l'OS) pour éviter que mon appli devienne une porte d'entrée vers mes données mais aussi l'OS (l'obstacle VM marche dans les 2 sens).
Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.
Dans tous les cas, quand tu utilises une plateforme, il faut que le modèle de gestion mémoire soit clairement exposé (et normalisé), pour assurer l'interopérabilité entre les composants. Alors désolé, mais y'a pas de "juste milieu", faut choisir quelque chose de standard pour la plateforme. En C/C++, c'est le joyeux bordel, chacun y va de sa technique exposée par ses libs. Dans les plateformes plus modernes, ca a été heuresement évité et normalisé : y'a un GC, il a un comportement dont les specs sont écrites noir sur blanc afin de garantir que toutes les implémentations produisent les mêmes résultats : interopérabilité.
Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime.
Justement ! Ces plateformes peuvent accueillir de nouvelles syntaxe/sémantique tout en profitant des services offerts !
Genre je prends .NET/Mono, certains voulaient une syntaxe ala Python, on a vu fleurir IronPython et Boo, et les composants écrits dans ces langages sont interopérables avec les autres composants sans qu'il n'y est de "pont" à écrire.
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.
Donc tu codes tout en C/C++. (et encore C++, y'a une gestion des exceptions et tout, y'a des services au runtime, ouahou, allé, C seulement !)
Et bien amuse toi bien, code ton serveur d'application en C, tes pages dynamique en C, tes clients lourd en C, amuse toi bonhomme, pendant ce temps là y'en a qui s'amuse avec d'autres plateformes : Java, Python, etc.
Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.
Ben justement, et en l'occurence en matière de serveur d'application, d'outil de mapping objet/relationnel, d'outils d'analyse de code, ben j'en ai marre de réinventer la roue dans des langages de bas niveau, je préfères largement utiliser celle de libs Java qui existent depuis des années.
C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C
Avec des perfs de merde. Merci. Compare ce qui est comparable bordel ! C'est pour ca que je te parlais de Zope !
Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.
Un calcul avec autant de mauvaise foi montre ton incompétence total.
Enfin au final t'es vraiment d'une incohérence totale dans tous tes propos. Moi j'essai juste de te démontrer que les VM apporte de réels atouts et avantages que les langages bas-niveau n'offre pas, que ce soit en matière de sécurité, de déploiement, de simplicité, d'interopérabilité, bref de productivité.
Toi tu fais quoi : tu cherches uniquement à dire le contraire de ce que je te dis. Un coup tu me dis que les langages de bas niveau c'est mieux, un autre coup tu me ressorts Erlang alors que c'est architecturé de la même manière que les plateformes que je prends en exemple, quand je te dis "oué mais tu peux pas profité de l'introspection quand tu code en C/C++" tu me dis "oué mais y'a Python etc.".
Bref tu te fou royalement de ma gueule, t'es inccapable de tenir une argumentation cohérente, on sait pas si t'aime bien les VM, un coup tu dis que tel ou tel langage c'est bien parcque pas de VM, un autre coup l'autre est bien aussi (parcqu'il en a une), ton seul objectif c'est de cracher avec une totale mauvaise foi sur des plateformes qui ont été initiées par des grosses boîtes. Si ca peut te faire bander, continue tout seul. (Ah oui au fait, Erlang, c'est pas issu d'une grosse boîte par hasard ? Bouuuuuh beurk.)
MonoFrance
[^]Re: Former des développeurs Python/Zope compétents
Oui timaniac... tu as raison. Je suis d'accord avec toi et tu as fait de très bon posts. Mais slyware est un incompétent. je crois qu'on doit se rendre à l'évidence, il est nul en informatique et en développement. Ce mec est un vrai boulet et en plus, il est de mauvaise foi !
[^]Re: Former des développeurs Python/Zope compétents
Je ne serai pas aussi tranchant que Stéphane, mais m'est avis que tu perds ton temps.
[^]Re: Former des développeurs Python/Zope compétents
Je crois que tu peux t'arrêter, là, on est tous d'accord, on a tous compris, sauf l'autre là, qui va poster encore une réponse, une variante des précédentes... Plus la peine de répondre, tout a été dit. Laisse-lui le dernier mot, celui qui tombe dans une salle de conférence déserte...
[^]Re: Former des développeurs Python/Zope compétents
En fait tu te fou vraiment de ma gueule.
Je viens de regarder vite fait Erlang...
Erlang a une VM qui se base sur l'interprétation d'un byte-code dans le but affiché est d'avoir une indépendance de la plateforme au niveau binaire.
Rrien qu'en comptant les sources écrites en C, y'a 41000 lignes, et j'ai pas compté les lignes codées en Erlang, qui doivent correspondre aux libs de base.
Ensuite Erlang a un environnement d'exécution qui offre de nombreux services (mémoire, distribution, chargement à chaud, etc.).
C'est vraiment une plateforme du même type que .NET/Java au niveau architecture.
Ah moins que Erlang aussi ca soit naz ?
MonoFrance
[^]Re: Former des développeurs Python/Zope compétents
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
Hu ? IronPython est plus lent que Python.
http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...)
Visiblement le libre est incapable de gérer une plateforme d'une telle taille de manière cohérente
???
Les "plateformes" du libre, ce sont les distributions, comme Ubuntu, Debian, Mandriva & co. Question taille, il n'y a pas à rougir.
[^]Re: Former des développeurs Python/Zope compétents
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.
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é. 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.
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?
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.
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).
[^]Re: Former des développeurs Python/Zope compétents
Tout à fait, linux est inmaintenable, python non plus, ruby non plus, KDE, gnutls; openssh; xorg, mozilla, gcc.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é.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.
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.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.
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...
[^]Re: Former des développeurs Python/Zope compétents