Jabber.org se tourne vers un serveur propriétaire

Posté par  (site web personnel) . Modéré par tuiu pol.
Étiquettes :
21
26
jan.
2010
XMPP
Le site jabber.org a été le premier à offrir un service de messagerie instantanée basée sur XMPP, en 1999, avec comptes gratuits. De 1999 à février 2006 le logiciel libre jabberd (GPL, C/C++) a été utilisé. Puis une migration vers un autre serveur libre, ejabberd (GPL, Erlang), a eu lieu.

Leur site est en train de migrer, péniblement apparemment, vers un serveur non libre (M-Link d'Isode Ltd), qui semble avoir du mal avec la charge du site. Le choix d'une solution propriétaire est étrange, lorsque l'on connaît le nombre de serveurs libres existants, que l'on met ses annonces sous « Creative Commons Public Domain License » et que l'on vante les clients Jabber/XMPP libres. Initialement, les critères de choix incluaient potentiellement du libre.
L'annonce d'origine datant du mois d'août dernier reflète bien les retards dans cette migration, comme cela a été évoqué sur le journal de xiloynaha sur DLFP.

Un large choix de services XMPP à base de serveurs libres existe (jabber.ru, jabbim.cz, jabster.pl, jabberes.org, jabber.fr, talkr.im, etc.)

Parmi les utilisateurs présents récemment sur LinuxFr.org, on notera du @jabber.fr (25%), du @gmail.com (19%), du @jabber.org (11%), du @im.apinc.org (10%), du fritalk.com (1,5%), etc. (sur 154 domaines différents).

Aller plus loin

  • # En même temps...

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

    En même temps, quand on regarde l'état des serveurs libres, c'est pas trés brillant.

    Jabber.apinc.org doit régulierement rebooter car ejabberd a des fuites mémoires ( qui sont censé être corrigé ceci dit, mais en même temps, il était déjà pas censé en avoir à la base :/ ), et les admins ont choisi ejabberd car jabberd 1.4x avait aussi des fuites. Djabberd, utilisé par livejournal, n'est quasiment plus developpé ( je doit être un des 3 utilisateurs dans le monde ).

    Openfire, c'est du java avec des morceaux de jar que j'arrive pas à identifier, ce qui le rends douteux à mon sens niveau license et niveau maintenance.

    Il ne reste que tigase, prosody, jabber2 et divers trucs ultra mineurs. Je doute que prosody tienne la charge ( c'est pas vraiment son optique ), je sais pas si jabber 2 est encore trés developpé ( je doit reconnaitre que j'ai pas cherché, donc si ça se trouve, c'est génial et tout ). Tigase a l'air sympa mais j'ai pas croisé le moindre utilisateur encore.

    Les gens intéressés peuvent voir la liste des serveurs sur le wiki de jabberfr, sur http://jabberfr.org/ ( wiki qui aurait mérité plus sa place dans les liens que la moitié des liens présent, mais bon... )

    Donc voila, c'est peut être ça qui fait que la XSF a décidé de mettre tout le monde a égalité.

    Pour ma part, je pense que c'est quand même un signe fort ( mais que je vais me faire huer pour l'avoir pensé en ces termes ). Autant ça me fait chier pour la crédibilité du libre, autant je pense qu'un standard, ç'est un truc qui doit aller au dela du logiciel libre, et donc qu'on doit aussi mettre en avant quand une boite privé et propriétaire arrive à faire un truc avec, tant qu'elle respecte le standard.

    Si les serveurs jabbers libres répondent pas aux critéres de la XSF en terme technique, il faut se tirer les doigts du cul et faire mieux la prochaine fois.

    Au passage, je pense que les problémes sont plus du à du hardware defectueux ( http://www.jabber.org/2009/12/migration-update/ et http://identi.ca/notice/20025686 ) qu'autre chose.

    La preuve, si on regarde les notices d'il y a quelques mois, encore sous ejabberd , on voit aussi des plantages du serveur :
    http://identi.ca/notice/7116810 ou , par exemple http://identi.ca/notice/4837558 , et des problémes réseaux, etc.

    Jabber.org n'a jamais été connu pour sa robustesse.

    • [^] # Re: En même temps...

      Posté par  . Évalué à 6.

      'même si, techniquement, un logiciel libre “n’est pas forcément toujours le meilleur, il l’est toujours éthiquement…'

      C'est pas moi qui le dit.

      Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

      • [^] # Re: En même temps...

        Posté par  . Évalué à 10.

        Je suis d'accord mais si ton logiciel ne répond pas à tes besoins/aux besoins de tes clients ça te fait une belle jambe qu'il soit meilleur éthiquement.

      • [^] # Re: En même temps...

        Posté par  . Évalué à 10.

        et si les gens qui, anciens utilisateurs de MSN, passent à jabber sur les insistances de quelques amis qui l'utilisent, ouvrent un compte sur jabber.org, et se retrouvent avec des problèmes de connexion, des latences ou que sais-je, est-ce que cela va faire une bonne pub à ce protocole ? Peut-être que les gens se barreront et retourneront à MSN, et diront que "jabber c'est trop nul, c tro len" etc.

        Si "éthiquement", utiliser un serveur propriétaire sur jabber.org permet d'intéresser plus de monde à jabber et de développer l'utilisation du principe de xmpp (et donc d'utiliser si on souhaite des serveurs plus décentralisés, et libres), est-ce que ce n'est pas cela qui est mieux ? C'est du pragmatisme.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: En même temps...

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

      > Donc voila, c'est peut être ça qui fait que la XSF a décidé de mettre tout le monde a égalité.
      (...)
      > Si les serveurs jabbers libres répondent pas aux critéres de la XSF en terme technique, il faut se tirer les doigts du cul et faire mieux la prochaine fois.

      Ce n'est une décision de la XSF. Jabber.org n'est pas le site de la XSF ( http://xmpp.org/ ).

    • [^] # Re: En même temps...

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

      La version libre d'Openfire représente un très bon serveur jabber.

      Openfire est écrit en Java et Openfire doit fonctionner avec OpenJDK.

      Les bibliothèques fournies avec Openfire sont :
      - activation : sous licence CDDL
      - bouncycastle : sous licence MIT X11
      - jdic : sous licence LGPL
      - mail : CDDL-1.0, BSD ou GPL-2.0
      - startup : GPL
      - comons-el : APL
      - hsql : BSD
      - jasper : APL
      - jtds : LGPL
      - mysql : GPL
      - postgresql : BSD
      - servlet : CDDL

    • [^] # Re: En même temps...

      Posté par  . Évalué à 7.

      En même temps, quand on regarde l'état des serveurs libres, c'est pas très brillant.

      [...]

      J'en déduis que tu t'es documenté sur ce point de vue.

      Comment se fait-il que les serveurs libres ne soient pas plus... stables (c'est ça)? Est-ce un désintérêt de la part des développeurs en général? Ou s'agit-il d'un projet trop complexe? Ou finalement Jabber n'a-t'il pas suscité suffisamment l'intérêt de la communauté (de développeurs s'entend)? Et pourquoi? Est-ce aussi la trop grande diversité des projets existants qui empêchent d'avoir des logiciels serveurs de qualité?

      J'aimerais comprendre. Même si ce ne serait pas catastrophique que les meilleurs serveurs XMPP soient propriétaire (temporairement du moins), ça devrait faire réfléchir et donner envie d'agir, si je comprends ton point de vue.

      • [^] # Re: En même temps...

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

        Ils sont très largement stable pour l'usage que tout le monde ou presque ici va en faire, je pense. Et en général de qualité suffisante pour qu'on puisse les faire tourner 24/24. J'ai pas eu de probléme spécifique avec ejabberd, pour une usage relativement modéré.

        Donc non, les serveurs actuels ne sont pas pourris pour la plupart des gens.

        Et je pense pas que le serveur proprio qui a été choisi s'en tire vachement mieux que les autres.

        Un serveur jabber, c'est un chouia ( à mon sens ) plus complexe qu'un serveur http. Il faut faire du parsing xml, du routage, du ssl, du sasl, et pour être utile, il faut une tripotée d'extensions, dont certaines vont assez profondement dans dans le coeur ( pubsub ), et tu peux aussi rajouter à ça une gestion de la persistance ( roster, avatar, etc ).

        Et bien sur, tu as beau avoir un standard, comme à chaque fois, les autres sont plus ou moins respecteux du standard, et le standard est plus ou moins implémenté complétement, ce qui est à corriger bien sur, mais à mon avis assez inévitable.

        Donc oui, on a plus de mal à maitriser ça que le dns, le web ou le mail. Et on a aussi moins d'expérience dans le domaine, le protocole n'a que 10 ans.

        Je peux me tromper, je précise , ça vaut ce que ça vaut, je vous invite à chercher par vous même plutot que de repeter mes bétises.

        Avec jabber.org, on commence à toucher des problèmes de l'ordre de celui ci : http://www.kegel.com/c10k.html

        Je sais que ejabberd a le support du clustering via mnesia, mais j'ai trouvé à l'epoque peu de doc, sauf à bien connaitre erlang et mnesia. Donc peut etre que le problème est que les serveurs actuels libres ont du mal à scaler horizontalement. Peut être qu'un jour, google proposera son code pour gtalk.

    • [^] # Re: En même temps...

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

      Supposer qu'un logiciel est exempt de bug ou de fuite mémoire c'est supposer que l'erreur n'est pas humaine ... ou que les développeurs ne sont pas humain ;-)

      Perso je pense que la seule chose dont on est sur c'est que ça va planter ... faut juste avoir suffisamment de machines et d'automatisme pour garantir la haute dispo. Après je comprend très bien que les moyens d'une asso ne sont pas les mêmes que pour une société en quête d'image.

    • [^] # Re: En même temps...

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

      pour djabberd seule la page principale n'est pas mise à jour
      il y a eu une release développeur en octobre

      http://search.cpan.org/~mart/DJabberd-0.85_01/

      mais je n'ai jamais essayé ;)

    • [^] # Re: En même temps...

      Posté par  . Évalué à 2.

      Openfire est le serveur embarqué dans Zimbra. Et ça fonctionne vraiment bien, sans avoir à être rebooté. Mais la charge entre une entreprise, et jabber.org n'a pas grand chose à voir et je ne sais pas comment Openfire se comporterait. Donc je n'en fait pas la promotion, juste un retour d'xp.


      mais M-Link n'a pas l'air non plus super riche en fonctionnalité.

      Je trouve qu'une version récente d'ejabberd aurait été une meilleure solution...

      Après comme toi je fais bien la différente entre standard, et open, mais dans jabber.org, jabber représente le standard, et org, quelque chose de non commercial.

      • [^] # Re: En même temps...

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

        En fait, d'aprés ce lien :
        http://mail.jabber.org/pipermail/juser/2010-January/006647.h(...)

        Il y a eu trés exactement 2 réponses :
        - tigase
        - isode

        L'équipe de jabber.org pense que le support de tigase n'aurait pas été suffisant, car visiblement ( enfin je pense comprendre ça ), c'est un petit projet avec 1 personne.

        À partir de ces éléments, forcement, isode a été choisi.

        Peter St andré le dit lui même, ils auraient pu être plus transparents, et vous essayer de s'améliorer la prochaine fois. J'imagine que par exemple, fournir les propositions sur le web aprés avoir décidé, afin que tout le monde puisse voir et comprendre ce qui a été fait.

  • # OVH

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

    Quelqu'un sait quel serveur jabber est utilisé chez OVH ?
    J'ai un compte chez eux, mais je n'ai jamais pensé à le demander.

    • [^] # Re: OVH

      Posté par  . Évalué à 4.

      Et chez Gmail? Parce que bon, je doute qu'ils acceptent des fuites de mémoire, et apparemment leur bousin tient la charge.

      Y'a pas des bidouilles pour trouver quel est le serveur Jabber utilisé par un service, en provoquant des erreurs par exemple, à l'image d'un serveur Web?

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: OVH

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

        A mon avis c'est un serveur maison.
        Il me semble même qu'au début le s2s (server to server) n'était pas implémenté.

        Ceci dit je n'en sais rien. Mais ça me semble bien dans leur façon de faire.

        • [^] # Re: OVH

          Posté par  . Évalué à 3.

          De mémoire, le s2s a toujours été implenté chez gmail. c'est sur skyblog (qui avait aussi un serveur xmpp que c'était le cas)

          Attention, cette information ne repose que sur ma mémoire et est donc, zut, comment on dit déjà ?

          • [^] # Re: OVH

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

            Implémenté, je ne sais pas, mais le s2s de gmail a été, pendant plus d'un an, coupé de l'extérieur. Comme ce n'était pas très utilisé à l'époque (il fallait toujours une invitation), c'est passé relativement inaperçu.

            Mes livres CC By-SA : https://ploum.net/livres.html

            • [^] # Re: OVH

              Posté par  . Évalué à 1.

              Exact, c'était pour mesurer les effets de SPIM.

  • # @im.apinc.org

    Posté par  . Évalué à 3.

    > Parmi les utilisateurs présents récemment sur LinuxFr.org, on notera du @jabber.fr (25%), du @gmail.com (19%), du @jabber.org (11%), du @im.apinc.org (10%), du fritalk.com (1,5%), etc. (sur 154 domaines différents).

    Juste une petite précision: le serveur im.apinc.org permet d'accueillir votre nom de domain.

    http://jabber.apinc.org/domliste.php

    Et donc, sur les 154 domaines différents, je suppose qu'un bon nombre y soit hébergés. J'y suis personnellement. Les statistiques sur ce domaine ne reflète donc pas totalement le nombre d'utilisateur de ce serveur.

    • [^] # Re: @im.apinc.org

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

      > Et donc, sur les 154 domaines différents, je suppose qu'un bon nombre y soit hébergés.

      En fait non : 25% de jabber.fr + 10% de im.apinc.org + 9 autres domaines avec un seul jabber_id.

    • [^] # Minitel 2.0

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

      Super, du Minitel 2.0 amélioré : vous êtes hébergés et vous ne maîtrisez pas vos communications, mais on donne l'impression que si.

      Sinon, pour les vrais qui en ont, il est possible d'héberger soi-même sa messagerie instantanée.

      • [^] # Re: Minitel 2.0

        Posté par  . Évalué à 9.

        Sans sauter à la gorge des gens, c'est bon de rappeler que:
        - n'importe qui peut héberger un serveur Jabber (faut quand même avoir une connexion à Internet),
        - jabber.org offre bénévolement un service gratuit.

        Donc, finalement, que jabber.org offre bénévolement un service gratuit basé sur un serveur propriétaire, c'est juste pas grave. Parce qu'il existe beaucoup d'autres serveurs, et parce que chacun est libre de monter le sien propre chez lui. C'est ça, le libre :)

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Minitel 2.0

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

        Je rajoute qu'une rapide installation d'ejabberd se résume de tête à :

        Aptitude install ejabberd
        Ouvrir deux ports sur son modem/routeur/parfeu/box
        Créer un compte admin

        Emule est plus dur à utiliser qu'ejabberd à mon sens :)

        • [^] # Re: Minitel 2.0

          Posté par  . Évalué à 3.

          Mouais, ejabberd a eu raison de moi. La seule subtilité c'était que je voulais servir plusieurs domaines, et ça a semblé trop (plantages au lancement, etc.).
          jabberd2 lui fonctionne avec plusieurs domaines sans trop de souffrances, même s'il a son lot de bugs (le stockage des mots de passe hashés fait tout planter, du coup ils sont en clair...).

          Bref, globalement, c'est pas terrible.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Minitel 2.0

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

            Suite à mon journal cité dans la dépêche, j'ai installé ejabberd en multi-domaines. Ça fonctionne au poil, du moins pour les trois domaines et la poignée de gens qui sont dessus actuellement. J'ai décrit l'installation là, si ça peut servir : http://wiki.lm7.fr/index.php/Installation_d%27un_serveur_Jab(...)

            • [^] # Re: Minitel 2.0

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

              De mon côté, fritalk.org est sous Ejabberd depuis un petit temps et c'est très très stable.

              La config est un peu obscure au début mais c'est relativement bien documenté. Là, je sers du multi-domaine avec certains domaines sur LDAP, d'autres pas, ce qui n'est pas trivial à mes yeux.


              Jamais eu de réelle fuite de mémoire avec plusieurs centaines d'utilisateurs simultanés. Par contre, Ejabberd utilise beaucoup de mémoire par défaut.


              Par contre, on a retiré les passerelles il y a quelques temps car c'était un boulot de maintenance beaucoup trop élevé et la plus grande source de plantage ou de remplissage de la mémoire.

              Mes livres CC By-SA : https://ploum.net/livres.html

  • # Diantre

    Posté par  . Évalué à -3.

    logiciel libre n'est-il plus synonyme de qualité supérieure? En tout cas, ça ne fait pas du tout s'ils passent à une solution proprio, même basée sur un standard...

    • [^] # Re: Diantre

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

      Il ne l'a jamais été. Un logiciel propriétaire peut être très bien codé...

      Il y a juste des probabilités importante qu'un logiciel libre soit plus "propre" qu'un logiciel propriétaire qui est souvent écrit vite dans le but d'être rentable le plus rapidement possible.

      • [^] # Re: Diantre

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

        « Il y a juste des probabilités importante qu'un logiciel libre soit plus "propre" qu'un logiciel propriétaire qui est souvent écrit vite dans le but d'être rentable le plus rapidement possible. »

        C'est vraiment de la généralisation à deux balles.

        Ce n'est pas parce qu' un logiciel est propriétaire qu'il a des deadline absolues.

        Ce n'est pas non plus parce qu'un logiciel est propriétaire que le département responsable de la qualité du code n'intervient pas pour protester.

        Ce n'est pas parce qu'un logiciel est libre et a du temps pour sortir ses versions qu'il n'est pas écrit par un pauvre étudiant qui débute en programmation et te fous plein de bugs partout.

        Ce n'est pas parce qu'un logiciel est libre qu'un contributeur bénévole a du temps pour corriger tous les bugs identifiés.


        Au final, je pense que les probabilités d'avoir du bon code dans un logiciel sont équivalentes en libre comme en proprio. La seule différence, c'est que sur du proprio, tu ne peux en général pas le vérifier.

        J'ai vu pour ma part autant de bouses en logiciel libre qu'en logiciel proprio.

        • [^] # Re: Diantre

          Posté par  . Évalué à -1.

          C'est quand même dommage de voir qu'un logiciel libre se fera remplacer par un logiciel propriétaire, alors que jabber n'est pas le petit projet.

          Est-il victime de sa popularité?

          Il est connu que, souvent, une petite équipe cohérente ira beaucoup plus vite et de manière beaucoup plus efficace qu'une grande équipe bordélique ou chacun fout son grain dans la machine. C'est pour cela, à mon avis, que de plus en plus de projet comment en mode fermé puis est ouvert une fois qu'il est bien stable (Compiz,...). N'atteind-ton pas les limite du "100% libre"?

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Diantre

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

      > logiciel libre n'est-il plus synonyme de qualité supérieure?
      en fait il ne l'a jamais été
      on peut écrire beaucoup de daube en libre ... (celui qui a dit hurd est prié de ne pas rire trop fort !)
      par contre, c'est, parfois (souvent) une conséquence du modèle de développement

      • [^] # Re: Diantre

        Posté par  . Évalué à 1.

        on peut écrire beaucoup de daube en libre ... (celui qui a dit hurd est prié de ne pas rire trop fort !)
        Faudrait peut être qu'il soit écrit pour ça ...

  • # Pourquoi cette solution?

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

    C'est étrange... Passer du libre au privateur (pour faire plaisir à RMS) est un choix que je peux concevoir. Cependant il montre, selon moi, une méconnaissance du principe libre. N'y a-t-il pas de SSLL qui pourraient leur coder/fixer ce qu'il manque dans ejabberd? Ou ne peuvent-ils pas le coder eux-même?

    Parce que là ils vont de toute façon devoir payer des licences de M-Link, me trompe-je?

    • [^] # Re: Pourquoi cette solution?

      Posté par  . Évalué à 3.

      Je n'ai pas trouvé le prix des licences sur leur site
      Néanmoins, faire développer et éventuellement maintenir du code tierce est à mon avis bien plus cher. Surtout que les experts erlang ne courent pas les rues.

      • [^] # Re: Pourquoi cette solution?

        Posté par  . Évalué à 2.

        La licence, ça ne doit pas être grand chose en effet, par contre, la migration… visiblement, ça ne se fait pas tout seul non plus et ça a du avoir un gros coup (financier ou humain ou les deux).

      • [^] # Re: Pourquoi cette solution?

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

        Quelle idée de faire du erlang aussi! o_o°
        Je ne savais pas que ejabberd était codé avec ce langage.

        Je vais être pragmatique, mais peut-être que la solution pour qu'une solution libre prenne le pas c'est qu'elle soit documentée et codée dans un langage plus commun?
        Je doute qu'Apache aurait connu la même notoriété s'il n'avait pas été codé en C.

        [aucun rapport]
        Je fais un petit test sur les guillemets: " (ceci est le caractère guillemet)
        Car la prévisualisation m'affiche " au lieu du caractère
        [/aucun rapport]

        • [^] # Re: Pourquoi cette solution?

          Posté par  . Évalué à 1.

          ceci dit, avec cette logique on peut abandonner tout les langages de dev
          parlerait t'on encore de ruby sans rails et metasploit ?

          de plus erlang à tout de même certains avantages théoriques, je dis en théorie, car normalement tout les problèmes cités plus haut ne devrait pas apparaitre en erlang:
          -il tourne par dessus une vm (qui est sensée gérer la mémoire, mais à prioris il le fait mal)
          -il est sensé "s'auto réparer": erlang marche par un système de processus qui tournent de manière parallèle, si un processus tombe, la vm est sensée le relancer automatiquement
          -il est sensé pouvoir monter en charge facilement, chaque processus pouvant être très rapidement déployé sur d'autres machines, on peut même laisser le programme "s'autodeployer"

          erlang a été (est?) tout de même utilisé par des grosses boites de telecom comme ericsson et nortel

          bon ce que je dis, cest tout ce que javais plus glanner sur ce langage il y a quelques années, je ne l'ai jamais pratiqué sur un vrai projet

          [aucun rapport]
          Moi aussi il me met des &quote quand je met des " dans mon texte, mais au final ça s'affiche correctement
          [/aucun rapport]

          • [^] # Re: Pourquoi cette solution?

            Posté par  . Évalué à 4.

            Ce n'est pas forcement la faute à la vm erlang pour les fuites de mémoire. On peut très bien avoir une fuite de mémoire avec des langage comprotant un ramasse-miette, par exemple avec une structure de donnée style table de hachage ou tableau associatif qui serait global dans le code.

            • [^] # Re: Pourquoi cette solution?

              Posté par  . Évalué à 1.

              +1 et dans ce cas la les performances sont pires qu'avec un langage sans GC ou la mémoire non utilisée peut être swappée car la majorités des GCs vont périodiquement balayée cette mémoire 'en trop'.

              Mais cela peut aussi être la faute du GC, certains GC sont dit 'conservatif' (tel le Boehm GC très utilisé) et peuvent induire des pertes mémoire sans que le programmeur ait fait d'erreur..

            • [^] # Re: Pourquoi cette solution?

              Posté par  . Évalué à 2.

              Jcomprends pas trop pourquoi en fait
              si cest en global cest que cest nécéssaire au bon fonctionnement de l'appli, donc on ne peut pas parler de fuites, si les éléments non nécessaires ne sont pas déférencés... bon cest que cest crade mais ça arrive à tout dev, néanmoins la fuite ne devrait pas être si dur à localiser...

        • [^] # Re: Pourquoi cette solution?

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

          Erlang permet de gerer trés facilement la "clusterisation" de ton serveur, ce qui permet une mise à l'échelle horizontale en cas de monté de la charge ( à condition d'avoir les compétences, et que je ne raconte pas de la merde avec du jargon que je maitrise pas :) ).

          Ejabberd est pas le seul gros projet en erlang, tu as aussi couchdb, un des fers de lance du mouvement nosql, et qu'on retrouve notament derriére UbuntuOne, le service proprio de Canonical. La aussi, on se retrouve avec un systéme facilement clusterisable, qui monte à l'echelle en rajoutant des serveurs, etc.

          Je pense pas qu'Erlang soit un mauvais choix, et c'est pas si complexe à utiliser, j'ai vu largement pire et moins documenté ( genre le ncl : http://www.ncl.ucar.edu/, lors d'une mission dans un laboratoire à Paris ). Mais faire des opérations avancés comme traquer une fuite mémoire, c'est complexe, en erlang comme en C. Et je pense que les admins de jabber.org ont aussi commencé par se tourner vers process-one avant tout.

Suivre le flux des commentaires

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