bobefrei a écrit 160 commentaires

Euh System.Collections n'a strictement rien d'innovant, ils peuvent toujours essayer et obtenir un brevet, un prior art sera facile à démontrer.

Les entreprises comme Microsoft et Sun détiennent des brevets pour lesquels il est possible de démontrer un "prior art". Seulement qui dans le monde libre va leur faire un procès? Un procès est un processus long, couteux et pénible. En plus sur ce genre de problème, il faudrait faire un procès dans chaque pays ou zone juridique. Mêmes les multinationales qui ont des services juridiques capables de le supporter réflechissent à deux fois avant de faire un procès.


A la lecture de tes posts, tu sembles convaincu que Microsoft ne posera pas de problème par rapport à un projet libre comme Mono. En plus des divers liens donnés ici, j'aimerai rajouter une petite histoire:

Lorsque j'étais membre du bureau de la Junior Entreprise de mon école, j'ai eu à remplacer quelqu'un pour aller chez Microsoft. Je ne savais pas trop de quoi il s'agissait et une fois là bas je me suis retrouvé dans un brainstorming sur un projet de site web destiné à faire la promotion de Microsoft aux élèves d'écoles d'ingénieurs. Tout d'un coup la discussion a dérivé sur les licences et sur les logiciels libres. Je leur ai dis que je pensais qu'il était inutile pour eux de se justifier sur un tel site. Les employés de Microsoft sont devenus hargneux et m'ont fait clairement comprendre que le libre était l'enemi a abattre. Ils avaient presque la bave aux lèvres en disant que c'était "franco-français" (l'insulte suprême chez eux apparemment...) de penser qu'on pouvait tout avoir gratuitement et que ça allait détruire l'industrie du logiciel. Microsoft considère que les logiciels libres sont des concurrents et comme tout concurrent, ils doivent être soit écrasés soit réduit à une part de marché négligeable.

freedesktop.org et les autres initiatives du même genre c'est de l'intéropérabilité pas de l'intégration telle que tu l'as décris. De plus n'importe qui peut s'en écarter s'il y trouve un intérêt.

Si l'implémentation de frameworks propriétaires est possible en libre, c'est parce qu'il n'y a pas de choix de conception à faire. Implémenter une norme prête beaucoup moins à discussion que définir une norme.

C'est juste que le libre n'a pas les moyens de gérer un framework de cette ampleur.

Pas les moyens ou pas le besoin? Certainement un peu des deux, mais beaucoup de développeurs sont satisfaits d'utiliser LAMP&co et sont plus productifs avec.

Et on a toujours le choix, la preuve y'a .NET ET Java. Si on suit ton raisonnement le libre devrait proposer une alternative à ces 2 là, juste pour le plaisir d'avoir le choix.

Pas pour le plaisir, mais pour pleins de raisons:

- avoir des outils vraiment libres, non soumis à des brevets et des contraintes légales (actuelles ou potentielles).
- pour innover.
- parce que la norme n'évolue pas assez vite.
- pour palier à des défauts de conception fondamentaux de ces plateformes.
- parce que telle fonctionnalité n'existe pas ou est mal géré par la norme
- parce que se faire dicter la loi par une norme propriétaire est pénible.
...
- parce que il y aura toujours quelqu'un pour avoir un besoin spécifique qui lui fera choisir une voix différente!

Et puis je ne dis pas "le libre DEVRAIT", mais "le libre PROPOSE". Si les solutions que j'utilise ne sont pas des alternatives à J2EE et .NET pour toi tant pis. Elles le sont pour moi et pour nombre de développeurs.

Si tu trouves que les développeurs libres ne font pas ce que tu veux, tu peux soit mettre la main à la pâte, soit retourner jouer sous windows et payer des licences.

Alors oublie l'idée d'un framework libre de ce type qui ne soit pas une implémentation d'un propriétaire.

Pour avoir un framework aussi intégré, il faut une et une seule vision que tu n'auras pas avec des développeurs libres d'implémenter leurs idées sans contraintes.

Le libre préfère l'intéropérabilité à l'intégration, sinon on aurait un seul environnement graphique, un seul système de fichier, un seul navigateur web, une seule API...

Si par "évoluer", tu veux dire copier une à une les fonctionnalités de Java/.NET, effectivement les seules plateformes que tu vas trouver sont les implémentations libres de Java/.NET.

L'alternative oui, mais identique.

Faut sortir un peu du monde java de temps en temps! Le terme RPC désigne à la fois un paradigme et un protocole (celui de Sun il me semble). En tant que paradigme, RMI c'est du RPC appliqué aux langages objets. Si pour un autre langage tu compares les versions Java de RPC et RMI, ça n'a pas de sens. Surtout ici où Erlang est un langage fonctionnel, non objet et donc pour lequel invoquer des "méthodes" ne correspond à rien. Pour te montrer un peu à quoi ressemble Erlang, voici le code d'un serveur RPC ( tiré de http://www.unsw.adfa.edu.au/~lpb/seminars/erlang-intro.html(...) ):

%%% start - rexec server on this node
start() -> 
    Pid = spawn(rexec, server, []),
    register(rexec, Pid),
    Pid.

%%% server - master server loop listening for next message
server() ->
    receive
        {From, Ref, M, F, A} ->
            io:format("rexec: handling ~w~n", [{From, Ref, M, F, A}]),
            spawn(rexec, handler, [From, Ref, M, F, A]),
            server();
        Error ->
            io:format("rexec: ERROR received~w~n", [Error]),
            server()
    end.

%%% handler -> handle current rexec request
handler(From, Ref, M, F, A) ->
    Res = (catch apply(M, F, A)),
    From ! {Ref, Res},
    Res.

Je l'ai dis, le support de plateformes et technos hétérogènes.

Tu l'as dit, mais pas expliqué. Même avec J2EE tu auras d'autres technologies qui rentreront en jeu, ne serait-ce que Javascript, SQL, XML... L'architecture que je propose se base sur deux outils (et encore on pourrait tout faire avec un seul), pas 10000. Tu ne te sers que d'une fourchette pour manger? Pas de couteau et de cuillère parce que ce n'est pas intégré et unifié? :-)

C'est bien ce que je dis, ca ressemble plus à du LAMP

Dans ce projet, on aurait pu tout faire avec Python, Erlang ou PHP, mais nous voulions apprendre ces technologies. De plus, LAMP est aussi intégré que Java: L pour Linux, Java a besoin d'un OS pour le faire tourner. A pour Apache, une interface web même J2EE demande un serveur web. M pour MySQL, il y a aussi une base de données derrière ton système Java. P pour PHP, c'est ici que Java prends place. De toute façon, pour recentrer le forum, la question n'est pas intégré ou hétérogène, mais est-ce que ces plateformes libres peuvent elles répondre aux mêmes problèmes que Java/.NET avec leurs solutions à elles (intégré ou pas).

Erlang est fait pour faire des applications réseaux et des clusters, autant l'utiliser dans une configuration qui convient. Surtout si tu veux gérer des centaines de millers de client.

Mais ça marche très bien avec de petites configs, car la gestion de la concurrence (très importante pour ce genre d'applications) est très légère par rapport à Java. Mon wiki tourne sous Yaws sur ma vieille machine (P700) avec une connexion 512 et est réactif même avec de gros téléchargements en parallèle.

Dans l'architecture décrite, c'est Yaws (http://yaws.hyber.org/) qui correspond aux JSP.

Pour remplacer RMI, on peut faire du RPC (qu'est-ce que ça de ridicule? RMI est un mécanisme de type RPC...) ou utiliser le système de messages d'Erlang (accessible via des API C++, Python, Java, C#).

Pour les web services, je n'en ai jamais fait avec Erlang donc je ne sais pas comment ça marche.

Pour la maintenance, je ne vois pas quel problème tu auras en plus par rapport à une solution J2EE (à part la difficulté de trouver des gens compétents dans cette technologie, mais là c'est un problème de type l'oeuf et la poule...).

Un exemple proche de ma "combo qui tue" était mon projet de fin d'étude: un moteur de recherche de mp3 sur le web distribué (en Erlang), une interface web en PHP et un programme en Python pour calculer un "taux d'affinité" entre une musique et un utilisateur.

Pour une architecture n-tiers classique,avec vraiment besoin de puissance, je verrais comme alternative à J2EE:

- un cluster Erlang côté serveur pour les traitements.
- un serveur Yaws pour l'interface web.
- un client lourd écrit en Python ou même en C++.

L'ensemble a de grandes chances d'être plus performant qu'un ensemble 100% Java, car Erlang n'est peut être pas performant pour les calculs, par contre sa gestion des processus et du réseau est beaucoup plus légère que celle de Java. De plus si tu as besoin de puissance, tu ajoutes une ou deux machines au cluster pour gérer la montée en charge.

Comme mesure de performance d'Erlang (et surtout Yaws) dans le domaine web, je connais ce comparatif: http://www.sics.se/~joe/apachevsyaws.html

Peut être que quelqu'un en a d'autre?

Tu cherches un concurrent ou une copie? Ou alors pour toi un concurrent crédible doit être obligatoirement un Java amélioré?

>Ah parcqu'en Java on est obligé d'arrêter le programme ?

Tu fais comment? Je n'ai pas vu cette possibilité dans Java...

>Pourtant moi j'y vois surtout des inconvénients.

Lesquels? Si tu n'utilises pas cette possiblité, elle ne va pas te manger!

>il suffit de lire un bouquin de design pattern pour s'apercevoir que beaucoup de collaboration font appelle à des interfaces.

Tu veux dire "un bouquin de Design Pattern appliqué à Java"? Si tu en lis un consacré à Python, ils implémenteront ça d'une autre façon.

Si tu as 100000 utilisateurs avec gestion de transactions, Erlang n'est-il pas plus pertinent que Java?

Que tu trouves que l'intégration de Java/C# soit un point positif rend-t-il impossible l'utilisation de plateforme plus hétéroclyte comme alternative?

Tu mélanges un peu tout:

- le typage fort est bien pour détecter les erreurs à la compilation, mais le typage de Java n'est pas non plus super contraignant: pour cela il faudrait regarder du côté d'ADA ou d'Eiffel avec la programmation par contrat...
- ce n'est pas parce que tu n'as pas trouvé d'usage "industriel" de la modification dynamique d'une classe qu'il n'y en pas. (Moi j'en vois un: mettre à jour un programme sans l'arrêter.)
- quel est le rapport entre la notion d'interface et la sécurité?

Je ne connais pas bien JTA, mais je suis en train d'écrire un utilitaire de synchronisation de bases de données en Erlang et je m'en passe très bien, car ce langage a toutes les API nécessaires pour implémenter des transactions.

Pour Python, il me semble qu'il existe plusieurs solutions de persistence et donc il doit y avoir de quoi gérer les transactions.

Côté performance, c'est difficile de comparer, mais on peut voir que Java et Python sont assez proche sur ce test: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=fullcpu&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&ackermann=1&binarytrees=5&wc=3&fannkuch=3&fasta=3&harmonic=1&knucleotide=4&mandelbrot=4&nbody=3&nsieve=3&nsievebits=2&methcall=0&pidigits=2&random=3&raytracer=5&regexmatch=4&revcomp=3&spectralnorm=2&spellcheck=4&hello=0&sumcol=3&takfp=1&tcpecho=2&tcprequest=4&tcpstream=3&process=2&message=5&wordfreq=5

Erlang est bien en dessous, mais il n'y a pas de comparaison en environnement distribué...

Au niveau IDE, qu'il y a des plugins Python et Erlang pour Eclipse.

Concurrencer ne veut pas dire faire la même chose avec les mêmes solutions. Ce n'est pas parce que Python, Erlang ou PHP ne sont pas identiques de C# et Java que leur utilisation n'est pas pertinente pour les mêmes types d'applications.

Pour la réalisation de sites webs, par exemple, toutes ces plateformes proposent des approches différentes adaptés à leurs langages, leurs API...

Je trouve la démarche très intéressante, mais je ne suis pas sûr qu'il faille faire apparaître sur la facture, car cela pourrait ressembler à un don forcé. Par contre tu peux expliquer à part que tu prends sur ta rémunération de quoi faire des dons pour les logiciels libres.

Pourquoi ne pas adopter une langue simple, capable d'être comprise par tous et à portée universelle?

Je propose comme candidates:

- l'esperando
- le novlang
- le C++

Si tu comptes faire évoluer, une piste serait peut être de parler des autres plateformes capables de concurrencer Java et .NET et de vérifier si elles sont vraiment libres.

Personnellement, j'en vois deux: Erlang et Python.

Gnome et QT incluent aussi beaucoup d'API non graphiques...

Techniquement les contraintes sont:

- des distributions et des configurations très différentes (librairies installées, organisation des fichiers...).
- des API différentes ou ayant un comportement différent par rapport au monde M$.
- différent de système de packages.

Commercialement:

- le portage coute des sous.
- pas assez de joueurs sous linux.

Bref rien d'insurmontalbe, la grosse contrainte c'est de prendre le temps et l'argent de faire le portage et les tests, car les jeux sont rarement OpenSource et donc on ne peut pas compter sur des contributions utilisateurs.

QT? Les API Gnome?

N'existe-t-il pas suffisamment de langages et d'API libres et non soumis à des brevets pour que l'on puisse se passer de .NET et Java?

Il y a peut être un compromis qui permettrait aux fabricants de matériels de garder secret leurs spécifications tout en permettant à n'importe quel système d'utiliser toutes leurs fonctionnalités: mettre les "pilotes" au niveau du Bios. Ce dernier prendrait en charge l'accès bas niveau au matériel tandis que l'OS gèrerait des tâches de plus haut niveau.

Pour les cartes graphiques, cela pourrait donner comme fonctionnalités:

- au niveau du Bios: changement de résolution, affichage de primitives...
- au niveau de l'OS: gestionnaire de fenêtres, dessin de formes complexes, scenegraph...

Tiens oui! Je me disais bien que j'avais déjà entendu parler de quelquechose dans le genre. C'est dommage que ça soit si enfoui. Il faudra que j'envoie un mail aux développeurs pour leur proposer de faire apparaître une icône ou un message dans la barre d'état pour informer et sensibiliser les utilisateurs.

Si les gens ont envie de parler de politique sur linuxfr, tu n'y peux rien.

La multiplication des journaux s'expliquent par la volonté de vouloir relancer un débat sur un même sujet, mais en partant sur d'autres bases.

Si les navigateurs actuels ont tant de mal avec les standards ce n'est pas seulement parce que ces derniers sont complexes, mais aussi parce qu'un bon navigateur doit pouvoir afficher un maximum de sites, même ceux qui ne respectent pas les standards.
Si les browsers web refusaient d'afficher un site dès qu'il contient la moindre erreur, les webdesigners seraient contraints et forcés de respecter les standards. Seulement pour satisfaire les utilisateurs, un bon navigateur se doit d'afficher les pages les plus pourris coûte que coûte pour rester compétitif par rapport à ses concurrents.

Pour résoudre ce problème, je vois une solution: ajouter un mode "strict" aux navigateurs avec la possibilité de repasser en mode normal lorsque l'on arrive sur un mauvais site afin de sensibiliser les utilisateurs et de permettre aux développeurs web de tester leurs créations. On peut même envisager des versions uniquement "strict" pour avoir un programme plus léger et plus stable.

Il me semble d'ailleurs qu'il existe des choses dans ce sens (Amaya par exemple).

<blockquote>Si les médias étaient tout puissants et entièrement dévoués à comploter pour vous faire voter oui, le NON ne l'aurait pas emporté dans 90 des 100 départements (chiffres sortis de mon pif).</blockquote>

C'est peut être justement parce que les médias étaient trop pro-oui que cela a incité beaucoup de gens à creuser un peu pour se faire leur propre opinion.