Sommaire
On m'a récemment demandé d'expliquer pourquoi je trouve que ZeroMQ est un sujet de rigolade. En guise d'introduction, j'aimerais préciser qu'un panel d'experts concertés sur le sujet ont eu des réactions similaires lorsqu'ils ont été exposés à deux lignes de ZeroMQ :
< Krunch> 1149 event.data.connected.addr = (char *)addr_;
< Krunch> 1150 event.data.disconnected.fd = fd_;
< Krunch> avec event.data qui est un union
< s> ahah
< n> nice
< n> http://i.imgur.com/pejxB.gif
Le reste de ce journal décrit mon contexte et comment j'ai été amené à abhorrer ZeroMQ (ci-après désigné « zmq » mais je vais aussi mentionner 0mq et ØMQ histoire d'avoir tous les mots clés). Initialement je voulais finir par une tentative de généralisation qui m'aurait permis d'insulter plus ou moins subtilement toute personne possédant un compte github mais ça sera pour une autre fois.
serpents et mangoustes
Je ne suis pas vraiment un développeur. J'écris du code mais de manière générale, mon rôle est plutôt de faire en sorte que les développeurs puissent en écrire. Dans le contexte de ce journal, ça veut dire que je ne développe pas d'application qui va utiliser zmq et de par ce fait, je me tape le popotin de la qualité de l'API, des performances top moumoutes et de l'architecture révolutionnaire du bousin.
De mon point de vue, je veux un logiciel qui fait ce qui est écrit sur la boite, qui soit packagé ou packageable facilement et qui reste relativement stable sur la durée de vie de l'application/système.
pourquoi je bois
Ma découverte de zmq a commencé quand il a fait sont apparition dans une liste de composants qu'ils m'ont été demandé d'intégrer à un système que je maintiens.
Le dit système étant basé sur CentOS 5, mon premier réflexe a été de vérifier si zmq n'était pas déjà dans la distribution de base ou un repo tierce « de confiance ». On trouve effectivement un paquet zeromq-2.1.9-1.el5 dans EPEL. Il s'avère cependant que ce paquet (crée il y a environ un an) est « trop ancien », que l'API qu'il expose n'est plus compatible avec celui pour lequel les développeurs veulent travailler et qu'il n'est plus maintenu par les développeurs de zmq. Un point de moins pour la stabilité donc. Après quelques tentatives de négociations je cède et me lance dans le packaging de La Chose.
Je commence donc par examiner le site web de zmq pour obtenir la dernière version stable. Il s'avère que la version recommandée est une release candidate (3.2.0-rc1). Peu engageant mais soit. Par bonheur, un fichier .spec (ce qui décrit comment construire les RPMs) est fourni. Malheureusement il n'est pas maintenu et ne fonctionne pas. Plutôt que d'essayer de le corriger, je reprend donc le .spec du paquet EPEL qui fonctionne immédiatement quand je le fais pointer vers la bonne version de l'archive (et j'ai plus confiance en les mainteneurs EPEL pour écrire des fichiers .spec corrects qu'en la plupart des autres développeurs).
Mission accomplie donc. Sauf que quelques jours plus tard on se rend compte que la création des RPMs zmq échoue une fois sur quarante deux. Plus précisément, un des tests intégrés segfault occasionnellement.
Examinons donc le core :
tests$ gdb .libs/lt-test_shutdown_stress core.12342
[...]
[New Thread 12912]
[New Thread 12911]
[New Thread 12910]
[...]
Program terminated with signal 11, Segmentation fault.
#0 zmq::session_base_t::monitor_event (this=0x2b304179d000, event_=256) at session_base.cpp:279
279 socket->monitor_event (event_, args);
(gdb) list zmq::session_base_t::monitor_event
[...]
275 void zmq::session_base_t::monitor_event (int event_, ...)
276 {
277 va_list args;
278 va_start (args, event_);
279 socket->monitor_event (event_, args);
(gdb) l
280 va_end (args);
281 }
[...]
(gdb) p socket
$1 = (zmq::socket_base_t *) 0x0
On a visiblement un object session_base_t dont le membre socket est NULL de manière inattendue. Voyons ce qui se trame plus haut dans le stack :
(gdb) up
#1 0x00002b304014a487 in zmq::tcp_connecter_t::close (this=0x2b30413cd000) at tcp_connecter.cpp:291
(gdb) l zmq::tcp_connecter_t::close
...
280 void zmq::tcp_connecter_t::close ()
281 {
282 zmq_assert (s != retired_fd);
283 #ifdef ZMQ_HAVE_WINDOWS
...
288 #else
289 int rc = ::close (s);
290 if (unlikely (rc == 0))
291 session->monitor_event (ZMQ_EVENT_CLOSE_FAILED, endpoint.c_str(), zmq_errno());
292 errno_assert (rc == 0);
293 #endif
294 session->monitor_event (ZMQ_EVENT_CLOSED, endpoint.c_str(), s);
(gdb) l
295 s = retired_fd;
296 }
Pour les gens qui sont allergique au C++ (comme moi), il peut être utile de préciser que "::close" fait juste référence au symbole "close" en dehors de tout namespace C++ (je suis sûr que cette phrase n'est pas strictement correcte mais j'ai pas mes specs sur moi). Ce qui signifie qu'à la ligne 289 on exécute l'appel système close(2) sur le file descriptor "s". Si cet appel réussi, on fait un truc relatif à ZMQ_EVENT_CLOSE_FAILED (truc dans lequel on segfault).
Si vous avez l'impression que ça n'a pas de sens, c'est normal. Je suis pas sûr de la raison exacte du segfault mais cette méthode ne devrait vraisemblablement pas être appelée avec ces arguments à ce moment là.
Un examen du code se trouvant dans le repo git suggère que le problème a été corrigé ou en tout case que le code concerné a été réécrit :
297 void zmq::tcp_connecter_t::close ()
298 {
299 zmq_assert (s != retired_fd);
300 #ifdef ZMQ_HAVE_WINDOWS
...
303 #else
304 int rc = ::close (s);
305 errno_assert (rc == 0);
306 #endif
307 socket->event_closed (endpoint.c_str(), s);
308 s = retired_fd;
309 }
Il n'y a d'ailleurs plus d'appel à session->monitor_event donc plus de raison de segfaulter de cette manière.
Je retourne donc sur le site web pour voir si une nouvelle rc ou même la release est disponible et corrige le problème. J'y trouve bien une nouvelle rc mais pour une nouvelle version. Apparemment, 3.2.0 n'a jamais été releasé. On passe directement de 3.2.0-rc1 à 3.2.1-rc2 qui contient le changement cité ci-dessus et bien d'autres (dont des modifications d'API). On a donc affaire à un projet qui ne fait que des release candidates et qui ne corrige pas les bugs dans une « release » donnée. Soit. Si la dernière release candidate corrige le problème, n'en n'introduit pas d'autre et reste compatible, ça me va. Niveau compatibilité, c'est déjà raté puisque le changelog indique des renommages de symboles mais on peut espérer que ça demandera pas trop de travail à adapter.
Je récupère donc la dernière release candidate, adapte le fichier .spec et tente de builder les RPMs. Le test qui posait problème passe mais maintenant il y en a deux autres qui échouent systématiquement. On a donc affaire à un projet qui release avec des régressions…
Examinons quand même ce qui échoue exactement :
zeromq-3.2.1$ make check
[...]
test_connect_delay running...
Rerunning with DELAY_ATTACH_ON_CONNECT
Running DELAY_ATTACH_ON_CONNECT with disconnect
lt-test_connect_delay: test_connect_delay.cpp:80: void* server(void*): Assertion `rc != -1' failed.
/bin/sh: line 5: 18715 Aborted (core dumped) ${dir}$tst
FAIL: test_connect_delay
zeromq-3.2.1$ gdb tests/.libs/lt-test_connect_delay tests/core.18715
[...]
[New Thread 10358]
[New Thread 10357]
[New Thread 10354]
[New Thread 10353]
[New Thread 10350]
[...]
Core was generated by `/tmp/zeromq-3.2.1/tests/.libs/lt-test_connect_delay'.
Program terminated with signal 6, Aborted.
#0 0x00002ab8d7bec285 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00002ab8d7bec285 in raise () from /lib64/libc.so.6
#1 0x00002ab8d7bedd30 in abort () from /lib64/libc.so.6
#2 0x00002ab8d7be5706 in __assert_fail () from /lib64/libc.so.6
#3 0x00000000004012b3 in server () at test_connect_delay.cpp:80
#4 0x00002ab8d721577d in start_thread () from /lib64/libpthread.so.0
#5 0x00002ab8d7c8fc1d in clone () from /lib64/libc.so.6
(gdb) frame 3
#3 0x00000000004012b3 in server () at test_connect_delay.cpp:80
80 assert (rc != -1);
(gdb) list
75
76 usleep (200000);
77
78 memset (&buffer, 0, sizeof(buffer));
79 rc = zmq_recv (socket, &buffer, sizeof(buffer), ZMQ_DONTWAIT);
80 assert (rc != -1);
81
82 // Start closing the socket while the connecting process is underway.
83 rc = zmq_close (socket);
84 assert (rc == 0);
(gdb) p errno
You can't do that without a process to debug.
TLS symbol `errno' not resolved for non-TLS program. You should compile the program with `gcc -pthread'.
Du coup je me retrouve à rebuilder le test avec un printf(strerror(errno)) pour voir l'erreur (si quelqu'un voit comment récupérer errno depuis ce core sans rebuilder, je suis preneur) et écrire un rapport de bug pas complètement inutile. C'est quand même dommage d'avoir un test qui fail sans qu'on puisse comprendre pourquoi rien qu'en regardant std{out,err} mais bon.
L'autre test qui échoue ressemble à ceci :
zeromq-3.2.1$ make check
[...]
lt-test_monitor: test_monitor.cpp:81: void* req_socket_monitor(void*): Assertion `!strcmp (event.data.disconnected.addr, addr)' failed.
/bin/sh: line 5: 12547 Aborted (core dumped) ${dir}$tst
FAIL: test_monitor
Le code concerné :
35 const char *addr;
..
42 zmq_event_t event;
..
57 switch (event.event) {
..
79 case ZMQ_EVENT_DISCONNECTED:
80 assert (event.data.disconnected.fd != 0);
81 assert (!strcmp (event.data.disconnected.addr, addr));
Si on cherche la définition de zmq_event_t on trouve ceci :
291 /* Socket event data (union member per event) */
292 typedef struct {
293 int event;
294 union {
295 struct {
296 char *addr;
297 int fd;
298 } connected;
...
331 struct {
332 char *addr;
333 int fd;
334 } disconnected;
335 } data;
336 } zmq_event_t;
Et en cherchant un peu, on trouve des trucs ainsi :
1144 void zmq::socket_base_t::event_disconnected (const char *addr_, int fd_)
1145 {
1146 zmq_event_t event;
1147 if (!(monitor_events & ZMQ_EVENT_DISCONNECTED)) return;
1148 event.event = ZMQ_EVENT_DISCONNECTED;
1149 event.data.connected.addr = (char *)addr_;
1150 event.data.disconnected.fd = fd_;
1151 monitor_event (event);
1152 }
On a donc data qui est une union et une écriture consécutive sur deux membres de l'unions. Si vous avez des notions de C, ça devrait vous donner des envies de meurtre. Quand on regarde les méthodes alentours on se rend compte que ce motif est répété à plusieurs reprises. Techniquement c'est correct (et n'est pas directement lié au problème déclenché par le test) car tous les membres de l'union sont des structs aux membres de mêmes noms et tailles dans le même ordre mais si le développeur se permet d'écrire des choses pareilles, j'ai assez peu envie de continuer de creuser.
J'ai donc remonté ces deux bugs (dont un était déjà connu) et ai soulevé le problème sur IRC mais ça n'a pas l'air d'émouvoir beaucoup les développeurs. Du coup, soit je commence à fixer des bugs zmq, soit je désactive les tests (puisque de toute façon les développeurs zmq ne les utilisent visiblement pas). Soit je convainc mes développeurs de se trouver une bibliothèque d'IPC moins bancale.
J'espère que le récit de mes mésaventures permet de comprendre pourquoi je n'aime pas zmq et si, quand j'ai le choix, je déciderai de ne pas l'utiliser. Il ne s'agit pas juste du fait qu'il y a des bugs ou même des régressions (ça arrive pour tous les logiciels). Mon problème est plutôt que le peu de code que j'ai examiné sent le copié/collé pas testé à 200 mètres et que le processus de développement/test/release du projet ressemble beaucoup trop à une vaste blague pour que je décide de baser quoi que ce soit qui devrait fonctionner plus de quelques semaines sur une telle bibliothèque.
Dallas
Un ami qui suit ce genre de choses a tenté de me décrire l'histoire de zmq. J'ai pas tout suivi et je ne me risquerais pas à tenter de résumer cette histoire ici. Ça m'a juste beaucoup rappelé les séries télévisées que ma grand mère regardais et j'ai l'impression que ça pourrait en partie expliquer les problèmes cités ci-dessus.
# M'enfin !
Posté par patrick_g (site web personnel) . Évalué à 10.
Et donc, pour ceux qui comme moi s'interrogent, ZeroMQ c'est "a high-performance asynchronous messaging library aimed at use in scalable distributed or concurrent applications".
[^] # Re: M'enfin !
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Dont l'un des principaux développeurs, Martin Sústrik, a forké le projet sous le nom Crossroads I/O et a publié un troll bien poilu sur C++ vs C : Why should I have written ZeroMQ in C, not C++ part I & part II.
[^] # Re: M'enfin !
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Et il bosse maintenant principalement sur nano, une reconception…
http://groups.crossroads.io/groups/crossroads-dev/messages/topic/5deqomx5OsZcKhpeVlJCMd
[^] # nanomessaging
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
C'est une version gamma ;-)
https://github.com/250bpm/nanomsg
[^] # Re: M'enfin !
Posté par Krunch (site web personnel) . Évalué à 3.
http://www.jwz.org/doc/cadt.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: M'enfin !
Posté par Krunch (site web personnel) . Évalué à 4.
Le premier article c'est http://www.joelonsoftware.com/items/2003/10/13.html
Le second est évident pour n'importe qui ayant passé plus de 5 minutes dans les sources du noyal.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: M'enfin !
Posté par Gof (site web personnel) . Évalué à 9.
Oui, mais…
1) Si il n'aime pas les exceptions il n'a qu'a pas les utiliser.
Il existe énormément de projets qui banissent les exception de leur code en C++.
2) Et pourquoi diable utilise-t-il std::list à la place d'un std::vector ? Et en plus son schéma est totalement erroné vu que les élément de la std::list sont allouée DANS le helper (donc pas d'allocation supplémentaire comme il le prétend). Si il veux vraiment utiliser une liste liée avec des pointeurs raw, rien ne l'en empêche, même en C++.
[^] # Re: M'enfin !
Posté par Batchyx . Évalué à 3. Dernière modification le 10 novembre 2012 à 22:01.
2) Monsieur utilise en fait des std::list<Object*>, donc son schéma est bon. Sauf que le mec qui utilise des std::list<Object*> en C++ pour stocker des Object (par opposition à stocker simplement des références vers Object), je comprend qu'il ai du mal avec la notion d'exception ou à faire du code qui ne leak pas dans tout les sens.
Ce que je comprend qu'il veut faire, c'est pouvoir allouer des SubObjectA et des SubObjectB directement dans les nodes de std::list, en gros allouer sizeof(helper)+ une taille arbitraire. Mis à part que je trouve l'idée horrible, il y a cinquante mille manières de faire ça en C++, que ça soit avec des conteneurs intrusifs, des variants ou un conteneur maisons qui fait ce que tu veut. Mais un objet qui est indépendant de son conteneur c'est bien aussi.
Enfin bref, la STL c'est bien, mais c'est limité (quand on voit la lenteur avec lequel c'est implémenté, mieux vaut que ça ne soit pas trop gros). Pour tout le reste, il y a Boost.
Ah, et l'orienté objet, c'est pas la panacée aussi. Surtout pour les performances.
[^] # Re: M'enfin !
Posté par GeneralZod . Évalué à 6.
Le fork est surtout dû à des divergences au niveau de la gouvernance du projet: Pieter Hintjens (aussi l'ancien employeur de Sustrik) veut un projet le plus ouvert possible [1], Sustrik et Lucina les principaux développeurs veulent une gouvernance plus restrictive [2].
Le plus marrant, c'est que Hintjens voulait au départ que zeromq soit écrit en C, mais que Sustrik et les autres développeurs d'iMatix avaient insistés pour utiliser C++. L'annonce de Sustrik de tout réécrire en C a été l'occasion d'un joli échange de piques :o)
[1] http://rfc.zeromq.org/spec:16 Le Contrat de Construction Collective de Code aka C4 résume bien le modèle basé sur les pull requests de github (et non git, Cf. la râlerie de Linus sur les pull requests de github)
[2] Aucun jugement de valeur, les deux modèles ont leurs avantages et inconvénients et les relations entre les projets sont amicales. En tant que hacktiviste, je trouve très intéressant le modèle C4 et pour le moment ça a l'air de fonctionner malgré le départ du principal développeur.
[^] # Re: M'enfin !
Posté par Guillaume Knispel . Évalué à 9.
Hm "Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias" sachant que "The project SHALL be hosted on github.com or equivalent, herein called the "Platform"", c'est quand même très très "mignon" comme exigence.
J'aurais énormément de mal à contribuer à un projet qui utilise Git et qui voudrait me faire ouvrir un compte sur github pour centraliser et accepter mes patchs.
Et si je continue à lire ce bordel j'ai quand même beaucoup de mal à me retenir de crier FOUTAISE en voyant des phrases comme "To maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;"
"reduces the risk of hijack by hostile entities." <-- hm en outre magnifique esprit logiciel libre tout ça…
"A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code." <-- magnifique efficacité; obligation de réinventer toutes les roues et impossibilité absolue de réintégrer des modifications des forks hostiles : MAGNIFIQUE !
"Maintainers SHALL NOT make value judgments on correct patches." hm pensons à l'état qu'aurait Linux (ainsi que divers autres projets) dans ces conditions et … OMFG ! Bien évidemment les exemples inverses de gouvernance complètement refermées, autoritaires et dysfonctionnelles abondent aussi. Simplement sur ce point choisir un extrême pour s'en prémunir d'un autre ne me convainc pas.
Bon bref, ptet que leur objectif de "maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks" est tenable, j'en sais rien, mais moi ça me donne pas envie.
Certains points font presque peur : "Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers."—hm certes, mais… pourquoi c'est nécessaire d'écrire ça ? On a besoin de l'accord, si c'est pas pour cette raison ???
L'intention sous-jacente de ce document est claire : si tu ose ne pas venir sur github (ou équivalent) on te parlera pas et tout code pondu en dehors de ce dogme méthodologique sera banni à jamais. Très bien, mais sans moi !
[^] # Re: M'enfin !
Posté par sustrik . Évalué à 10.
Sorry for replying in English, my French is terrible. I am the original author or 0MQ and yes, I think the problem described in the article has to do with governance. It's a new code that got into the codebase under new contribution model which doesn't require rigorous code review and extensive discussion of patches. That in turn leads to this kind of problems. The only thing I can do at the moment is to provide an alternative to 0MQ, which, as already mentioned above, I am already working on, but it'll take time to make it usable.
[^] # Re: M'enfin !
Posté par dyno partouzeur de drouate . Évalué à 4.
Pour les non-anglophones, voici une traduction (probablement pas très bonne). Inutile de pertinenter mon post, je ne le fais pas pour le karma whoring.
Désolé de répondre en anglais, mon français est affreux. Je suis l'auteur original de 0MQ et oui, je pense que le problème exposé dans l'article est lié à la gouvernance. Du code nouveau rentre dans le dépôt de sources sous un nouveau mode de contribution qui n'impose pas de revue de code rigoureuse ni de longs débats sur les modifications, ce qui provoque ce genre de problèmes. Ma seule possibilité pour l'instant est de proposer une alternative à 0MQ sur laquelle je travaille déjà comme dit ci-dessus, mais il faudra du temps avant qu'elle soit utilisable.
# assert (rc != -1)
Posté par Antoine . Évalué à 5.
C'est moi ou le code n'utilise que des assert() pour vérifier le code de retour des appels système (y compris ceux qui font des I/O) ? Comme les assert() sont supprimés en mode optimisé, c'est un peu inquiétant concernant la qualité du bousin.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . Évalué à 2.
Ça dépend de ce que tu appelles « mode optimisé ». Tu peux avoir -O4 et -UNDEBUG.
Mais dans ce cas de toute façon c'est des tests. J'espère bien qu'ils sont pas compilés avec -DNDEBUG (et de fait, ils le sont pas quand on fait un "make check" puisqu'il y en a qui abort()ent).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Guillaume Knispel . Évalué à 0.
Franchement, si un projet repose sur le fait que des assert doivent être conservés car ils contiennent des effets de bord fonctionnels, hm, RHAAAAAAAAAAAAAAAAAAAAAA
sérieusement
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . Évalué à 10.
Pour les tests, je vois vraiment pas le problème. Ces asserts sont dans le code des tests, pas le code du produit lui même.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par freem . Évalué à 2.
Ben, disons que c'est dans la même veine qu'écrire sur 2 membres d'une union à la suite: ça marche, mais ça laisse présumer du meilleur… ou du pire.
N'empêche, marrant que des dev capables d'accepter ce … truc… inqualifiable sur les union aillent reprocher au C++ leur bouletitude.
D'un autre côté, j'ai l'impression que les dev C qui critiquent le C++ ont partiellement raison, certains de nos confrères font du boulot de porc et se servent des capacités qu'apporte le C++ pour ça, donnant l'impression que C++ est la cause.
PS: ceci peut ressembler à un troll car je me suis contenté de lire l'article et les commentaires, jusqu'a ce point. Ah, non, j'ai aussi été voir leur site pour chercher à quoi ça sert cette lib, et j'ai pas trouvé (par contre j'ai très vite trouvé qu'ils parlaient de changer de manière de procéder en fonction de ce que les utilisateurs sont près à payer pour plutôt que les choses que les dev supposent utile. A méditer.)
Merci donc au premier commentateur qui l'a précisé.
[^] # Re: assert (rc != -1)
Posté par Krunch (site web personnel) . Évalué à 3.
Je ne suis pas d'accord. Cette histoire d'union est injustifiable. Les asserts sur les valeurs de retour dans le code de test me semble tout à fait valable. On pourrait faire mieux en définissant son propre assert qui ne soit pas désactivable avec NDEBUG et qui va printfer des infos pertinentes avant de faire rater le test mais utiliser assert(3) me semble tout à fait acceptable et requiert d'écrire/maintenir le minimum de code.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: assert (rc != -1)
Posté par Guillaume Knispel . Évalué à 2.
Tu as un problème à comprendre "effet de bord fonctionnel" ?
[^] # Re: assert (rc != -1)
Posté par Guillaume Knispel . Évalué à 2.
sérieusement, ya des gens qui m'ont moinsé pour ce que j'ai sorti ?
Je le redis donc, pcq les neuneus n'auront pas raison de ma sagesse suprème : "Franchement, si un projet repose sur le fait que des assert doivent être conservés car ils contiennent des effets de bord fonctionnels, hm, RHAAAAAAAAAAAAAAAAAAAAAA"
Et sérieusement, si des neuneus moinsent ça, j'espère au moins qu'ils ne codent pas, et qu'ils se font soigner.
sérieusement
# Merci de ta réponse construite et argumentée
Posté par GeneralZod . Évalué à 5.
Je ne m'attendais pas à une réponse aussi étoffée mais ça valait le coup d'attendre !
Je comprends beaucoup mieux ton point de vue même si je ne partage pas la conclusion finale (mais ça ne m'empêche pas de te pertinenter).
Plus haut, je parle du process C4 qui conduit le projet zeromq et je pense que c'est en bonne partie la source de tes mésaventures (et la raison du fork cité ci-dessus). Il est difficile dans un projet avec une gouvernance aussi ouverte d'avoir un vision à moyen et long terme cohérente mais également de s'assurer de la qualité du code.
À titre professionnel, même si zeromq n'est pas parfait, il a l'intérêt d'avoir une communauté active et de répondre à mon besoin: construire des applications distribuées (parfois polyglottes) et qui passent à l'échelle et tolérante aux fautes.
Pour info, les alternatives possibles étaient de loin pires encore -je précise dans mon contexte-: CORBA (mwhahahaha !), ZeroC ICE (git fermé, forum pour échanger des patchs qui s'accumulent, horrible à packager), Thrift (pétage régulier, horrible à packager), AMQP (RabbitMQ est intéressant mais packager toute la stack Erlang sur les Unix commerciaux ne m'emballait pas et toujours le problème du SPOF malgré le support des fédérations), etc …
[^] # Re: Merci de ta réponse construite et argumentée
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Dans un contexte un peu différent, mais qui (je pense) montre bien les soucis évoqués dans ce journal, et que je viens de croiser. C'est un contexte un peu particulier, c'est pour OpenBSD/sparc64 pour un univers alternatif. les «produits» concernés sont protobub et protobuf-c, de chez Google. Le but étant de faire tourner un serveur Munble en environnement ésotérique.
Lisez le log de la compilation, et posez-vous des questions sur la superficie des tests…
Indien un jour, indien toujours :)
# Moé
Posté par fredix . Évalué à 5. Dernière modification le 10 novembre 2012 à 20:47.
ZeroMQ est malgré tout utilisé par quelques projets comme mongrel2 et photon et selon ce tweet il Samsung l'utilise sur ses Galaxy S3.
De plus je l'utilise sur mon projet nodecast où zeromq me permet de transférer des tâches à des workers et même de transférer des fichiers à des workers. un schéma de mon archi qui fait certes usine à gaz, mais l'usage est très simple et permet de scaler facilement puisqu'il suffit de lancer une nouvelle instance d'un worker pour qu'il entre dans un pool push/pull, zeromq fait un round robin dans le pool de workers.
# Ouais, c'est ça.
Posté par 2PetitsVerres . Évalué à 8.
On dit tous ça. /o\
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Ouais, c'est ça.
Posté par stopspam . Évalué à 3.
Ça permet de se décharger lorsqu'une boulette survient.
# Mr X témoigne
Posté par Krunch (site web personnel) . Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Merci pour le feedback.
Posté par nl.dev . Évalué à 1.
Merci pour le feedback (donc). Par contre, ce qui est rapporté ici est assez en contradiction avec ce qui écrit ici : http://www.zeromq.org/topics:planning. L'approche "qualité/versioning/…" décrite ne semble pas respectée.
# Dommage...
Posté par roh01 . Évalué à 3.
C'est dommage que le ton de l'article ne soit pas un peu plus mesuré, car ZeroMQ propose une réponse originale et pertinente à une sujet difficile (les communications dans les applications distribués avec de fortes contraintes de performance et d'évolutivité). De plus, un excellent guide documente la librairie. Même sans l'utiliser, sa lecture est enrichissante : de nombreuses anecdotes issues de cas d'utilisation réels sont présentées.
Alors oui, le projet a un passé mouvementé. D'un coté, le principal contributeur était un génie passionné, un tantinet élitiste, et très protecteur vis à vis de l'évolution de son bébé. De l'autre, son employeur souhaitait que les changements soient concertés entre les développeurs et les utilisateurs.
Qui devait évaluer la pertinence des besoins exprimés par les utilisateurs ? Qui devait choisir la meilleure implémentation possible, et surtout quand la déployer ? ZeroMQ est utilisé à grande échelle par certaines entreprises, et briser les API sans concertation est le meilleur moyen de perdre des clients.
Tu montres clairement que la qualité des patchs communautaires peut laisser à désirer. Sur ce point, le génie a donc au moins partiellement raison. Mais t'es tu intéressé aux branches 3.0 et 3.1 ? Elles ont été créés unilatéralement par Martin dans sa quête du Graal de la conception logicielle. Elles n'ont jamais été publiées car sources de trop de bugs et dotées d'API différentes… C'est beau mais inutilisable. Et ça te tombe dessus, toi client, sans prévenir. Il y a peut-être un compromis à trouver entre trop d'ouverture et la dictature ?
Aujourd'hui, Martin a créé son propre fork et semble s'orienter vers une reconception plus ou moins partielle (cf autre commentaire). La branche 3.2 de ZeroMQ se remet des expérimentations qui ont eu lieu dans les branches précédentes et du départ d'un des principaux contributeurs. Derrière toutes ces péripéties, il y a des facteurs techniques et humains.
Je te trouve quand même très vocal sur un sujet aussi épineux alors que tu reconnais ne pas l'avoir vraiment suivi.
[^] # Re: Dommage...
Posté par Krunch (site web personnel) . Évalué à 4.
D'un autre côté si tu viens chercher de l'objectif modéré dans un journal DLFP taggué coup_de_geule, tu n'es pas forcément au meilleur endroit.
Je réitère donc mon opinion initiale à ce sujet : hahaha.
Non. Le premier paquet maintenu que j'ai trouvé était 2.1.9 et le site web recommande 3.2.
J'ai bien fait de pas m'y intéresser donc.
Certes. Et zmq ne l'a visiblement pas trouvé.
On m'a demandé mon avis, je le donne. Il m'arrive de me documenter sur l'histoire des projets qui m'intéressent mais zmq n'est pas un projet qui m'intéresse. J'ai juste eu à travailler avec et j'espère que le message est bien passé que je trouve que c'est de la merde.
Après les gens qui ont un avis différent et plus ou moins informé peuvent le donner en commentaire, dans un autre journal ou à la terrasse de leur café préféré.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Dommage...
Posté par Gilles G. . Évalué à 2.
Moi, à l'inverse de roh01, j'ai envie de te remercier pour ce journal qui m'a sans doute évité de m'engager avec une techno qui ne correspond pas à ce qu'elle prétend être.
Merci donc.
[^] # Re: Dommage...
Posté par nl.dev . Évalué à 2.
Krunch, ton article est basé sur une expérience malheureuse à partir de laquelle tu extrapoles sur la qualité globale du projet ZMQ. Je respecte ton point de vue mais conclure aussi radicalement ("c'est de la m…") est totalement abusif.
J'invite simplement les lecteurs en quête d'une techno de base pour leur futurs projets à ne pas s'arrêter à ton article.
Merci à roh01 d'avoir modéré ton propos et résumé l'historique du projet (ce qui aide grandement à avoir un peu de plus de discernement face à la mélasse zmq/crossroads-io/nano).
# alternatives
Posté par steph1978 . Évalué à 2.
sans l'avoir utilisé, je trouvais la solution zmq assez élégante.
y a-t-il des solutions équivalentes (donc libre) ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.