Victor a écrit 1388 commentaires

Je ne suis pas vraiment d'accord, si on veut un support de KDE, alors il faut que des gens le fasse, on fait du libre quoi.

Il y a des patch pour supporter KDE dans firefox (voir http://en.opensuse.org/KDE/FirefoxIntegration ou http://aur.archlinux.org/packages.php?ID=32598 ), maintenant il faut voir si ils remplacent le support de gnome par celui de KDE ou si il ajoute le support de KDE...

Le mieux serait bien sûr d'avoir un support de Freedesktop j'imagine...

Et tu peux nous en dire plus sur ce « c'est facile à activer sans changer le firmware » dans le cas du Hero ?

Oui, mais ce que le monsieur d'en haut te dit c'est que xmpp, ne détecte pas par magie la déconnexion d'un équipement, il ne fait rien de moins que ce que font les outils de monitoring actuels.

Bin si justement, c'est ça qui est cool ! Si on considère un équipement comme un user XMPP, alors XMPP gère tout ça et on peut effectivement se concentrer sur l'information qu'on passe plutôt de comment on la passe et si l"équipement en face est effectivement connecté.


Et nagios ne réinvente rien, il utilise ce qui existe déjà (snmp, etc)!

Là dessus je suis d'accord, c'est une erreur de ma part alors, mais ça ne supprime pas le débat sur "XMPP est-il adapté pour faire ça ?" !


Bien sûr que les machines communiquent, mais le contenu de leurs échanges n'est pas équivalent à ce que des humains se racontent (dommage qu'il n'ait pas perce dans ce domaine)

Oui, et ? XMPP est fait aussi pour ce genre d'échange à lire ce qu'écrive les autres...

Oui mais ça revient à faire un _contrôle régulier_, soit en pull, soit en push. Il me semble que XMPP ping[1] est d'ailleurs là pour ça.
Mais je restes persuadé qu'un ping ICMP est plus léger qu'un ping XMPP pour savoir si la communication entre le serveur de surveillance et la machine surveillée est toujours vivante.

Là dessus je veux bien te croire, mais l'argument en réponse à ça pourrait être qu'à notre époque, en échange d'aisance de développement et d'utilisation (voir la suite de ma réponse), on pourrait sacrifier un peu de BP.


Ensuite utiliser XMPP pour communiquer, c'est un autre sujet, mais pas abordé dans le journal.

J'ai plutôt le sentiment que c'est le sujet maitre du journal en fait : XMPP propose tout les services nécessaire au fonctionnement d'un outil comme Nagios.
Même si l'auteur du journal ne l'a pas mis en exergue, je pense que c'est là dessus que le débat devrait se concentrer au final (voir encore la suite de ma réponse pour plus de précision).


Hormis le fait que Nagios (1999) existait avant XMPP (2000 et 2004 pour le standard), donc ils n'ont pas réinventé en fait.

Faudrait pas non plus me prendre pour un imbécile hein (en même temps je l'ai un peu cherché par mon choix de vocabulaire :)
Bien sûr que Nagios était là avant, mais ça n'empêche qu'au lieu de se concentrer sur le quoi de leur boulot, les devs de Nagios doivent aussi s'embêter à développer le comment alors qu'il y a des outils qui se concentrent déjà la dessus et le font pas mal.
C'est aussi une histoire de réutilisabilité, bien sûr Nagios sait le faire, mais si il le fait, c'est pour s'en servir pour faire son boulot, pas le proposer à d'autre !

J'ai une petite déformation professionnel, je fais du génie log et j'ai tendance à tout voir sous forme de réutilisation et de composabilité :)

Entre autres :

L'idée proposée est d'envoyer un message quand ça va mal. Bien je soulignais que le problème venait lorsqu'on a une coupure de réseau on se retrouvait dans le cas suivant : pas de message donc pas de problème.
La solution pour ça a été de faire comme les navigateurs quand ils téléchargent un fichier et que l'on interrompt le téléchargement. Je réplique que l'on ne peut pas garder une communication ouverte sans rien dire indéfiniment (les serveurs peuvent fonctionner des mois sans problèmes).

C'est là où est le problème. Qu'on utilise XMPP ou n'importe quoi d'autres, on aura toujours besoin d'avoir le serveur qui va demander aux client "ça va ?" ou alors le client devra toujours dire "je vais bien ?".

Donc ce point n'est pas automagiquement résolu par XMPP.


Ce qu'il dit, c'est que si justement c'est résolu par XMPP car le protocole XMPP inclus déjà le fait qu'on check qu'une compte (une machine ici donc) est connecté ou pas.
En gros, si une machine = un user connecté, alors les autres users (le moniteur) savent si il est connecté ou pas.

En gros ce qu'il dit c'est qu'on pourrait utiliser XMPP et son modèle décentralisé comme couche transport pour se concentrer sur le contenu des messages sans qu'on ait à mélanger la gestion de la messagerie (push/pull, contenu structuré, etc) et l'utilisation qu'on en fait.
Et ça rejoint l'autre commentaire qui demandait ce que signifiait la différence entre messagerie instantanée et messagerie humaine : il n'y a pas que les humains qui utilisent les messages pour communiquer, NAGIOS lui-même le fait, sauf qu'ils ont tout réinventé pour le faire tandis que XMPP se concentre QUE sur ça !

Ah oui ça se tient :)

Donc en fait, on repose sur le "ping" de xmpp au final :)

Je suis plutôt d'accord avec toi sur toute cette discussion, mais je crains que tu n'ai mal compris un de ses arguments plutôt pertinent :


Il faut que tu m'expliques. L'idée de base présentée ici c'est que les serveurs surveillées envoient eux même un message quand il y a un problème. Si tu appliques cette solution, tu dois envoyer régulièrement un message pour dire que je suis vivant. Sinon tu reviens à l'idée d'un serveur qui poll les clients et ça élimine une partie des raisons d'utiliser XMPP.

Bah tu envois un message que quand il y a un problème (plus précisément quand tu change d'état), si tout va bien à l'instant N pas besoin de le répéter à l'instant N+1, le serveur garde en mémoire l'état de chaque client.


Ce qu'il dit c'est que si le serveur qui est censé envoyé un message pour dire que rien ne va plus a été déconnecté du réseau, alors il ne pourra pas envoyer ce fameux message, d'où l'intérêt d'un "ping" !

Et bien ça semble marcher ici, je verrais pour le proxy lundi, mais sinon il y a bien l'intégration avec les fenêtre de fichier de kde...

Je suis d'accord, mais il y aussi l'idée (répandue je pense) que le DRM est la solution technique parfaite pour refléter la vision du législateur.

Présenté comme ça, je suis entièrement d'accord :)

Et j'ajouterais que la JVM est capable de supporter de plus en plus de languages très intéressant (entre autres Scala et Clojure) tout en profitant de l'existant, ce qui en fait un support de dev vraiment super à mes yeux !

Peut-être d'un point de vue technique, mais du point de vue de nos chers législateur qui n'y captent pratiquement tous rien, c'est pas la même chose !!!

(Et à la fin on se retrouve avec des DRM pour que la technique rejoigne leur vision : tant qu'ils ne comprendront pas comment ça marche, ils ne voudront pas changer la façon d'aborder le problème et on fera des DRM ou équivalent.)

Quand on ne parle plus de durée ?

Plus sérieusement, le problème n'est pas la durée, mais que tu utilises ça comme un argument pour défendre Java (et donc la JVM qui est un truc super à mon avis).
C'est comme si tu disais d'un dev qu'il était bien parce qu'il avait encore rien cassé : c'est cool mais ça me donne pas envie de l'embaucher… (et encore, si je devais mettre ça dans un ordre du mieux au moins bien, l'ingénieur qui a rien cassé est mieux que l'appli qui tient une semaine).

Il y a pleins d'arguments super pour défendre la JVM, je ne crois pas que celui-là soit bien pour défendre quoi que ce soit (sauf Windows peut-être…).

Je suis le premier à défendre la JVM, mais "uptimes de plus d'une semaine" n'est pas vraiment un argument satisfaisant...

Ou Scala !

Oui, il y avait effectivement d'autres langages avant ceux cités !

Python ou … Haskell, Caml ou Scala pendant qu'on y est. Ce sont quand même des fonctionnalités qui ont été inventés dans et pour les langages fonctionnels.

Non, que les module Xorg de Nvidia ou ATI n'existeraient pas en réalité si ils se greffaient sur du code GPL !

C'est "backward-compatible" ! On reste avec du http, et si le client et le serveur le supporte alors c'est exploité, sinon non !

Les specs sont (seront) publiques si je ne me trompe pas.

C'est différent car c'est pas très difficile à mettre en place, il "suffit" que la prochaine version d'apache implémente SPDY puis que plus tard (ou avant d'ailleurs) la prochaine version de Firefox le fasse aussi pour que le protocole soit mis en place !
Rien d'autre à faire entre les deux, aucune conf spécifique, ça juste marche comme on dit par ici :)

C'est un peu ce que fais SPDY mais en ajoutant d'autres trucs en plus, non ?

Alors pourquoi ça marche alors que la seconde ligne, celle avec les u ne contient pas de rfkill ?

La seconde ligne n'inclut pas le rfkill unblock et rfkill block.

Tu es sûr qu'en fait ta touche fn+f2 elle ne marcherait pas sans configuration du tout ?

Avec des monads bien sûr !

Quelles quantités pour une première expérience ?